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Abstract | 
. Among its other eheracteristios;2 programming luaguage ‘saould be conducive to . 
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, ythematization of | their ) 
. semantics in the Se aciational style eine and Strachey. ‘Many real world Programpping . 
problems, such as operating systems and data base inquiry ‘systems, require @ program- 
ming language capable of non-determinacy because of the non-determinate behavior of 
their physical environment. To date, there has been no satisfactory denotational 
semantics of programming languages with nog-determinacy. This dissertation presents a 


straightforward denctational treatment of nou-determinate data flow programs as | 


functions from sets of tagged sequences to sets of tagged sequences. A simple complete 
partial order on such sets exists, in which the data flow primitives are continuous | 
functions, so that any data flow program computes a well defined function. Also 
presented are suggestions for extensions of this semantics, discussions of “fair”? non- 
determinacy and other questions, and the relation of this approach to other approaches. 
In particular, it is unnecessary to use the “power domain” construction in order to 
handle simple non-determinacy in data flow languages. 
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Introduction 


Need for Formal Semantics 


The success of syntax theory in making precise the syntax of programs led investiga- 
tors to attempt to describe the semantic behavior of programs with equal precision. In 
particular, in order to prove theorems about the behavior of programs, it is necessary to 
have a mathematically precise set of axioms which define how programs behave. These 
axioms define the way in which the elementary semantic units behave (where elementa- 
ry units are the basic data, operators, statements, etc.) and how the behavior of com- 
pound semantic constructs (such as expressions, statement lists, etc.) behave in terms of 


their components, elementary or compound. 


The major truth one wishes to be able to prove about a program is that it does what 
it is supposed to do. There are two ways of expressing this: that it meets some specifica- 
tion, or that it does what another program does (which is known correct). Proving that 
one program does what another does is usually called proving program equivalence, and 
is not decidable in general. Proving that a program meets some specification requires 
having a formal statement of that specification (which also must be known correct, a 
point sometimes overlooked) and then proving that the behavior of the program is 
consistent with the specification. Such specifications (usually expressed in predicate 
calculus, the ‘‘assembly language” of the specification world) are often more compact 
than an equivalent program known to work, but they are not necessarily more perspicu- 
ous, since they may contain much that is “‘non-constructive” which programs by defini- 
tion cannot. That a program meets its (formal) specifications is also undecidable in 


general. 


There are other things that one might want to prove about a program. The most 
common is that the program terminates for all of its ‘‘legal’’ input, that is; one wants to 
prove that its domain of definition is what one thought. A second property worthy of 
proof is that the program consumes (no more than) a certain amount of time or space; 


the efficiency of a program is almost as important as its correctness. Obviously, a 
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mathematically precise semantics for programs is needed in order to construct mathe- 


matical proofs such as these. 


There are three main approaches to precise semantics: the operational, the axiomat- 
ic, and the denotational or functional semantics. The operational approach, based on 
the notion of an abstract interpreter, is the most intuitive of the three, but it is rather far 
from the mainstream of mathematics, so that itis difficult to invoke many useful 
theorems or other tools. The axiomatic approach of Floyd [Flo-67] and Hoare [Hoa-69], 
which views a program as relating (in the mathematical sense) the “before” state of the 
abstract machine to its “after” state, has the disadvantages that it needs something that 
has a state, and that relations are less convenient than functions. The functional 
approach of Scott and Strachey [S&S-71] treats the semantic behavior of a program as a 


function from inputs to outputs, a well known kind of mathematical object. 


The tractability of the formal semantics of a programming language depends more 
on the elegance of that language than on the class of semantic model chosen, however. 
We will present a programming language whose semantics we trust is quite tractable, 


considering its scope. 


Need for Modularity 


If a program is large, it is important that it be decomposable into parts, called 
modules, each of which performs a well defined function (at least in the informal, if not 
the formal, sense). Furthermore, it is important that the interactions of the modules 
with each other be held down to a reasonable amount. That is, the functions performed 
should be as independent as possible besides being well defined. The purpose of 
modularization, of course, is to keep the program understandable, since it is the rare 
person who can comprehend a large system with many interdependencies. In fact, since 
the number of interdependencies can grow exponentially in the number of components 
(consider all K way interactions, for K $ N), one might consider the point of modulari- 
zation to reduce such exponential growth to a more tractable polynomial or even linear 
growth. If the program is quite large, a hierarchy of modules is more appropriate. Then 
each module at the top level is composed of modules, each of which is in turn composed 


of modules etc., until the modules are simple enough to be understood without further 
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decomposition [Sim-69]. This hierarchical decomposition need not be a tree, a submo- 
dules may be shared (e.g. both the carburetor and the automobile as a whole contain 


screws). 


A program which is well partitioned into modules also is more likely to be proved 
correct (assuming that specifications for it can be formulated). The approach to proving 
such a program, as one might expect, is to prove that each module properly implements 
its well defined function, and that the modules are interconnected so as to meet the 
overall specification. If the program is a hierarchy of modules, this process is repeated 


for each level of the hierarchy. 


Modules are often realized as subroutines, or more likely, in large programs, as 
collections of subroutines sharing data. An extreme case of modularization may be 
found in data abstractions as exemplified by the CLU language. Roughly speaking, data 
abstractions are collections of subroutines which provide and enforce access functions 
for an extended (e.g. user defined) data type. The way in which data abstractions differ 
from the ordinary way of providing access functions is that the only way to access 
objects of that type is through the subroutines of the data abstraction. Thus data 
abstractions assure that the program is modularized as claimed and that no one is 


“cheating” by violating the module boundaries. 


This thesis presents a language which is uniquely disposed towards modularization, 
both in its syntax and its semantics. Since its semantics is based on the mathematical 
notion of function, it is possible for modules to perform one function in the formal sense. 
Thus this language and its semantics may provide a basis for proving properties of large 


programs expressed in it. 


Need for Parallelism 


There are several situations in which parallelism is desirable or necessary in a 
programming language. The first situation is when the problem to be solved is inherent- 
ly parallel. The classic example of this is a multi-user computer system. Each user sits 
at a terminal making independent requests to the computer. Since the users are inde- 


pendent, and since persons live their lives in parallel with one another, it follows that the 
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computer system must be able to serve these requests in parallel (i.e. simultaneously 
with respect to an appropriate time granularity). In order to serve the requests In 
parallel, some part of the computer’s program must be capable of parallel operation. In 
the case of a regular time sharing system such as VM/370 (the purest case), it is only the 
supervisory program which operates in parallel, each user appears to have a virtual 370 
on which she runs her programs sequentially. In fact, operating systems in general need 
parallelism [Kos-73b]. 


The next case in which parallelism is desirable is when there is some hardware 
(especially CPU) with actual parallel Processing capacity and the user wishes his 
program to take advantage of it in order to run faster i in total elapsed time. A typical 
. example of this is performing weather (hydrodynamic) calculations on a highly parallel 

. “computer such as ILLIAC IV. Here, the extra speed gained. by performing calculations 
simultaneously on many grid points. makes the difference between useful answers and 
not (nobody wants to predict yesterday's weather). | - | 


These two cases of parallelism i in program operation are rather different. In the 
first case, the simultaneous operations tend to be ‘doing different tasks, while in the 
second case, they all are performing nearly the same computation, but on different data. 

. Different programming language approaches have been. adepted to. cope with these 
different cases. To handle the first case, multi-tasking. facilities often. haye-been added 
to an otherwise conventional programming language: For example, PL/I: has the TASK 
option on the CALL statement, which causes the: invoked procedure. to be run as an 
independent, parallel task or process. In ALGOL style languages, the parallel statement 
approach is favored; this is a compound statement whose component statements are to_ 
be executed in parallel with one another, rather than serially in the order they are 
written. In both these language classes, some syachronization operations are provided 
also because the parallel paths. are never totally independent of one another. 


The second kind of parallelism i is often handled without ‘any specialized features in 
the language, but is rather accommodated entirely by the compiler. For example, APL is 
a sequential programming language with array data and an extensive collection of array 


operators, but with no emphasis on parallelism. However, it is easy to imagine an 
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interpreter or compiler for APL programs which compiles in a fashion to take full 


advantage of the array processing parallelism of the ILLIAC IV. 


There is a third kind of parallelism that is desirable in programming that is not truly 
supported by any common programming language. That is parallelism for the sake of 
omitting unnecessary detail. The course of programming language development has 
been to create languages of ever “‘higher level”, where by higher level is meant a 
language in which less implementation detail need be specified. For example, FORTRAN 
introduced the notion of arithmetic expression, LISP the notion of automatic storage 
management, and most recently, CLU and others have introduced the notion of abstract 
data type, an advanced form of data representation independence. All of these lan- 
guages, however, still demand that the programmer specify that operations take place in 
some serial order, even though problem only demands that the operations take place in 
some partial order. The only case in which the exact order need not be specified is 
when the language has operations which operate on structured data as a whole; then the 

- order of operation on the components need not be specified. But if one is defining an 
operation on structured data, the irrelevant total ordering of component operations may 
again creep in. For example, in defining a complex add operation, it doesn’t matter 


whether the real parts are added first or the imaginary parts are added first. 


What is needed, then, is a programming language which supports all three kinds of 
parallelism, parallelism demanded by the nature of the problem, parallelism demanded 
by the need for execution speed, and parallelism needed to suppress unnecessary 


implementation detail. 


Need for Non-determinate Behavior 


Although it is generally considered desirable for programs to be determinate (to 
always give the same output when presented with the same input) there are certain cases 
in which determinate behavior would be crippling. Consider the classic example of an 
airline reservation system: it consists of a central computer(s) and data-base connected 
to a number of agents’ terminals. Each agent works independently, requesting informa- 
tion and booking reservations. Thus the behavior of the system must include some 


dependency on the arrival time of the transactions —— the last seat on a flight must be 
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given to the person who requests it first (where ‘‘first”” means at least € earlier). But 
such timing dependency is contrary to the notion of determinate behavior. If the system 
were to operate completely determinately, there would be no way for the system to 
transact with the agents at their convenience, but only according to a rigorous schedule. 

If one agent were out to lunch unexpectedly, for example, all the other agents would be 
delayed while the system waited for that agent’s response. The way out of this difficul- 
ty, of course, is to include the arrival time as part of the input data, then the time 
dependency reduces to a data dependency, which is determinate. However, the part of 
the system which performs this operation is itself nondeterminate, but it is an isolated 


singularity. 


The part of the system mentioned above which merges multiple sources of inputs 
into one output and perhaps tacks on the arrival time of each input is often called an 
arbiter. (The very act of merging several input streams into one output stream attaches 
an ordering to the arrivals of the separate inputs, so often an explicit arrival time may be 
dispensed with. ) Given such an arbiter, which merges several streams of inputs into one 
output stream, a question which is of much concern is the question of fairness, that is, 
whether the input streams get equal treatment by the arbiter. In particular, might inputs 
one some ports get accepted preferentially to inputs one some other ports, or worse yet, 
is it possible that the inputs presented at some input port be held up indefinitely while 
inputs from other ports are accepted freely. Both of these behaviors are conceivable for 
arbiters (since, by their very name, their merging is arbitrary) but, although the priority 
treatment of certain inputs might be desirable, the indefinite delay of some inputs when 


there are no other inputs is almost certainly undesirable. 


We may conclude from this discussion that a programming language must allow 
nondeterminacy but that it is rarely necessary to use it, and when it is, the arbiter seems 
to be an appropriate construct. The question then arises as to whether the nondetermi- 
nate arbiter operation which is provided is fair or not (and which meaning of fair 
applies). Therefore, any semantics of such a programming language surely must be able 


to cope with nondeterminacy and with the question of fairness. 
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Overview of Dissertation 


In an attempt to meet the four needs outlined above, this dissertation sets forth and 
analyzes an unconventional kind of programming language, called a data flow program- 
ming language [Den-73, Kos-73]. This semantics of this language is defined in terms of 
mathematical functions, yet the functions transform the data of interest rather than the 
state of the machine, so modularity is achieved easily by means of function composition. 
The two dimensional syntax of the language provides parallelism in a natural manner, 
both in terms of the elimination of detail and the specification on independent tasks. 
The ability of the language to operate on structured data means that parallelism of such 
operations is also possible. Finally, the language allows non-determinate programs, and 
has a relatively straightforward semantics for non-determinacy, but the language 
construct for non-determinism allows the programmer to isolate the non-determinate 
behavior in small sections of the program, thus allowing the analysis of most of the — 


program in the simpler determinate semantics. 


The major part of the dissertation deals with the denotational semantics of non- 
determinate data flow programs. The necessary domain for the functions is defined and 
its properties proved; then the primitive operators in the language are functionally 
defined and they are proved to have the necessary mathematical properties. In particu- 
lar, chapter 2 discusses and informally defines data flow programming languages, 
chapter 3 gives background on mathematical semantics, chapters 4 through 6 contain the 


formal definitions and proofs, and chapter 7 concludes with discussion of several points. 
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-2- 
Data Flow Programming Languages 


Background 


In recent years a new class of programming languages, called data flow languages, 
has evolved ([Den-73, Kos-73]. Unlike most programs, the execution of data flow 
programs is governed solely by the availability of data, both. input and computed, rather 
than by the movement of one or:more abstract locuses of control. A data flow program 
may be represented by a flowchart-like network of operators: connected by. data paths. 
Each operator executes when the data it needs is _present. on its input paths yielding 
transformed data on appropriate output paths. Operators are strictly local in effect, that 
is they can influence one another only by:means of data’ sent via the "paths. New 
operators may be defined as networks of: other: ie baci analogous to subroutines, and 
recursive definitions are permitted. 


Gus of the virtues. of data flow programming is that it allows parallelism to be 


expressed in a natural fashion. Furthermore, the paralielim canbe guaranteed determi- 


nate, if desired. The expression of parailelism is: one ‘of the early. reasons researchers 
were attracted to data flow. However, data flow is:ao0w:known.to have other advantages 
as well. ‘The two most important are locality of: effect: and. applicative behavior. . 
Applicative behavior means that data flow. operators:can be characterized as mathemati- 
cal functions. Locality of effect means that the mathematical equations for a data flow 
program can be derived simply by conjoining the equations for the various parts of the 
program in an ‘‘additive’’ manner. In spite of its applicative behavior, an operator may 
be.a function from input sequences to output sequences and thus exhibit an (internal) 
state with regard to single inputs and outputs. Therefore, data flow languages can be 
analyzed mathematically almost as easily as “toy” applicative languages (e.g. pure LISP) 
but are more powerful in that they provide parallelism and ‘‘state’’. 


Informal Semantics of DF PL, a Data Flow Programming Language 


The data flow language which will be considered in depth in this paper is a develop- 
ment of the author [Kos-73], and is called DFPL for brevity. 
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A DFPL program is a directed graph whose nodes are operators and whose arcs are 
data paths. Operators in DFPL functionally transform their inputs to their outputs 
without ever affecting the state of the rest of the program. Since there is no control 
flow, there is no GOTO; in spite of this, loops may be programmed as well as recursion. 
Most significant though, is the fact that unlike ordinary applicative languages, programs 
may exhibit memory behavior: that is, the current output may depend on past as well as 
current inputs. The effects of memory are local like those of other operators and it does 


not permeate the semantics of programs. 


Data in DFPL are pure values, either simple like numbers or compound like arrays 
and records. There are no addresses as primitive data in DFPL, although compound 
operators may be defined to interpret data values in a manner reminiscent of addresses. 
An operator “‘fires’” when its required inputs are available on its incoming paths. After 
an unspecified interval, its sends its outputs on its outgoing paths. It is not necessary 
that all inputs be present before an operator fires; it depends on the particular operator. 
Similarly, not all outputs may be produced by a given firing. A synchronous operator is 
one which fires only when all its inputs are present and it produces all its outputs at 
once. The outputs may depend on past inputs as well as current inputs. If the outputs 
of a synchronous operator depends only on current inputs, the operator is said to be 
simple. Synchronous operators are analogous to: subroutines (with ‘town’ or “‘static’’ 
variables if the operator is not simple). Some operators produce a time sequence of 
output values from one input value or conversely; they are analogous to coroutines. The 
operators in a DFPL program thus operate in parallel with one another subject only to 


the availability of data on the paths. 


An operator may either be primitive or defined. An operator is defined as a 
network of other operators connected by data paths such that some paths are connected 
at one end only. These paths are the parameters of the defined operator. An instance 
of a defined operator operates as if its node were replaced by a copy of the network 
which defines it and the parameter paths spliced to the paths which were connected to 


that node. This ‘‘copy rule” allows recursive operators to be defined. 


Sufficient synchronization signals are passed with the data on the paths so that 


operators do not fire prematurely, and so that operation of the program as a whole is 
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independent of the timings of the component operators (at least in basic DFPL, full DFPL 
allows timing dependent programsin order to cope. with the real world). 


Classes of Operators 


There are three classes of operators in DFPL: simple: operators, including the usual 
_ arithmetic, logical and aggregate operators stream. operators, including the primitive 
Switch operators (for conditionals and other data routing) and primitive Hold operator (for 
memory and iteration); and non-determinate operators, including the primitive Arbiter. 
(for coping with the non-determinate. physical world). Simpie operators all have the 
property that they demand all their inputs to fire, ‘whereupon they produce - all their 
outputs. Furthermore, each firing i is independent of any past history, that is, the 
poeraior is a & function from current input | to current output. 


eee operators Sinalnaee - not oy, produce all phair inputs/outputs, or their 
current output may depend on past inputs. Thus we can not describe their functional 
behavior as simply as before (not producing an output.is not: the same as producing a 
null output). But we can describe their behavior if we view them as functions from 
streams (sequences over time) of inputs to.streams of outputs. Not. all computable 
functions from streams to streams describe stream operators. however; the function must 
be causal, that is, the operator may never retract some. output upon receiving further 


input. 


Non-determinate operators produce any one of a set of output values (according to 
whim, or in a real implementation, timing considerations) when presented. with specified 
input values. The primitive Arbiter. operator, upon which other non-determinate 
operators may be based, takes as input two or more streams. and produces as output a 
stream which is the result of merging the input streams in some arbitrary way. Non- 
determinate operators may be viewed as relations from streams to streams, or more 
profitably, as we. shall soon see, as functions from sets of streams to sets of streams. 


Synchronous operators allows us to avoid the tedium.of using a separate index for 
the stream of values on each data path. All paths in a subnetwork of synchronous 


opérators may share the same stream index since that subnetwork behaves as a single 
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synchronous operator. Note that all simple operators are synchronous and stream 
operators may or may not be synchronous. Also, any defined operator constructed 


entirely out of synchronous operators is itself synchronous. 


Primitive Operators 


There are five primitive operators in basic DFPL (shown in Figure 2.1). Of these, 
two are simple in their behavior: the Fork and the primitive computational function or 
Pcf. The Fork is a multi-output identity function, that is, a copy of its input is sent to 
each of its outputs. The Pcf is really a whole set of operators including the usual 
arithmetic, logical and aggregate operators (e.g. Construct and Select). The Modify 
operator is an example of a Pcf which typifies DFPL in that it generates new data rather 
than updating existing data. Modify takes three inputs, an array A, an index J and a 
value V, and produces one output, a new array Anew, which is a copy of A except that 
Anew,= V. Note that the Fork and all Pcf operators are synchronous. Since Forks 
have such simple functional properties we do not treat them as explicit operators on 


proofs, but rather just label all their paths the same. 


The most complicated of the primitive operators are the Switch operators, also 
shown in Figure 2.1. These two operators have the property that each firing is inde- 
pendent of previous firings, but not all inputs/outputs are demanded/produced upon 
each firing. The outbound Switch or Oswitch, for example, demands C and JU as inputs 
for each firing, but only one of X, Y and Z receives output in any firing. Which one 
receives the output, which is just the input value U, is determined by the value of the 
input C. The inbound Switch or Iswitch operates conversely, only one of the inputs X, 
Y, Z is accepted upon firing (C is always demanded), and its value is always sent out on 
U. 


Informally speaking, an [switch merges two or more data streams into one data 
stream of the same length as the control stream, selecting which input data stream to use 
next according to the current value on the control stream. Conversely, an Oswitch splits 
a data stream into two or more data streams dependent on the values of the contral 
stream. Figure 2.2 exemplifies the behavior of both Iswitch and Oswitch according to 


which paths are input and which are output. In both cases, the ordering(s) of the output 
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stream(s) is consistent with the ordering(s) of the input stream(s). Although. the value 
of an output from a Switch is dependent only.on.the current. input values for. this firing, 
the position of that output value in its stream is dependent on previous firings, hence 


neither Switch is-a simple operator. 


Since these operators sometimes do not demand/ produce ‘inputs/ outputs, we can 
not describe their functional behavior as simply as before (not producing an output is not 
the same as producing a null output). ‘But we can describe ‘their behavior if we view 
~ them as functions from streams of inputs to streams of outputs. 


The most interesting primitive operator in basic DFPL is that which behaves like a 
kind of memory cell. It is just a holding station” that is, the ‘output is what the input was 
on the previous firing and the initial output i# its constarit paratticter. That is, Out’t! - 
In’ and Out'=Q. The Hold operator is lsterastiig becaust it is sufficient to construct 
any kind of memory desired, yet itself is put ely yal Calb sit from inpit streams to 
output streams). It can also be used to construct iteration. ae 


All of the above primitive operators are causal i in the ‘sense that an output cannot be 
affected by future inputs; that i is, once an n output is produced, i it cannot be changed. 


_ Some Conipound Operators ee a8 ca 


Switch operators are most often used in matched pairs, with the. control. input of 
each connected, via a Fork, to the same source of a:.control stream. _ When connected i in 
this way, the DFPL version of a conditional expression results,.as. shown..in Figure 2.3. 
The equivalent expression is If P(X) Then F(X) Otherwise G(X). | 


Figure 2.4 shows a definition of a- repesting constant operator. This operator takes 
no inputs but produces an (infinite) stream of outpat values,. all ‘the same (Q). 


A fancier memory cell is shown in Figure. 2. 5. When : a. 0 ) value i is. . presented on the 
control path C, the current contents is read. out onto path Y. _ When al value is present- 
ed on C, and a data value presented on input path Z, the cell igs updated to contain that 
new data value. The cell has an initial contents of Q. 


iv 


The Primitive Non-determinate Operator 


To allow the construction of programs with indeterminate behavior, we define an 
operator which merges its input streams in an arbitrary manner. This operator, called 
the Arbiter, is shown in Figure 2.6. Speaking informally, the Arbiter operator merges 
two or more input streams into an output stream whose order of items is consistent with 
the separate orders of items in the input streams. This merging is done randomly (or 
arbitrarily) analogous to shuffling together two decks of cards. The Arbiter also 
(optionally) generates a stream of control values which tells exactly how the merge was 
performed. This control stream is of a form such that if it is fed to an Oswitch, the 
merged stream can be unscrambled into its component input streams. The optional form 
of Arbiter can be programmed from the more primitive form, which does not generate 


the control stream output, together with a Fork and an Iswitch. 


Since the Arbiter produces an output stream chosen randomly from a set of possible 
output streams, we might characterize the Arbiter as a relation from input streams to 
output streams. However, since the the fixed-point theory of functions is better under- 
stood, we will treat the Arbiter as a function from (sets of) input streams to sets of 
output streams. We consider sets of input streams even though intuitively the Arbiter 
works on individual input streams because we wish the domains and codomains to be 


compatible. 


In extending the semantics of DFPL to accommodate the Arbiter, the semantics of 
the determinate operators must be upgraded also. This upgrading is the obvious one of 
saying that the determinate operators map sets of input streams into sets of output 
streams pointwise, that is, each stream in the input set gets mapped to a single stream in 
the output set by applying the old stream-to-stream function of the operator. Multiple 
input operators are more complicated. If the input sets originate at the same Arbiter, 
then the operator is applied to corresponding streams from the input sets in a manner 
similar to an inner product of vectors. If the sets originate at different Arbiters, then | 
the operator is applied to the Cartesian product of the sets. If the sets have mixed 
origins, that is have some Arbiter in common which affected their computation, as well 
as independent Arbiters, then a mixture of inner and outer (Cartesian) products must be 
taken. Thus, the determinate operators produce output sets whose cardinalities are no 


bigger than the product of the cardinalities of the input sets. The indeterminate Arbiter, 
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unfortunately, tends to cause cardinalities to getout of hand, since the output set 
sardinalities depend on the input set elements (i.e. the number of ways they can be 


merged) as well as the input sets cardinalities. 


Examples 


The DFPL program shown in Figure 2.7 is an example of a procedure definition. 
The procedure performs the multiplication of two complex numbers with a high degree 
of parallelism. Figure 2.8 shows a DFPL procedure for computing the mythic recursive 
factorial function. Figure 2.9 shows a DFPL procedure which implements a random 
access memory of 1000 ceils, each initialized to 0. 


The program illustrated in Figure 2.10 takes advantage of the fact that the optional 
control output of an Arbiter may be used to control an Oswitch to unscramble the 
merging performed by that Arbiter. If the operator F is simple, that is, it is a function 
from its current input to its current output (thus independent of previous inputs), then 
the defined operator Triple-f behaves exactly as three copies of F applied separately to 
U, V, and W producing X, Y, and Z respectively (see Figure 2.11). However, the 
operator F is shared’ among the three input and output ~ paths and therefore saves 
resources as compared to three copies of F. Of course, this is at the cost of running at 
least three times siower. Most important, even though the: internals of Triple-f are 
indeterminate, the behavior of Triple-f as a whole is functional and thus determinate. 
Therefore, it is possible to construct determinate programs using indeterminate compo- 
nents, and furthermore, proving one has done so is not necessarily difficult. 


Other Data Flow Languages 


One of the earliest pure data flow models of programming was developed by 
Rodriguez [Rod-67] This provided most of the capabilities of DFPL except for operator 
definition, and, thus, recursion. Programs in this language were guaranteed determinate 


in operation. 


Luconi developed a model of parallel computation [Luc-68] which was more general 


in some ways than Rodriguez’s. However, because a relatively conventional sort of 
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memory cell was necessary to hold data for the operators (approximately one such cell 
per operator), determinate behavior could not be guaranteed, except by following strict 


conventions in programming. 


Adams developed a pure data flow programming language [Ada-68] similar to 
Rodriguez’s and DFPL except that data paths were FIFO queues of unbounded length. 
This makes direct hardware implementation impossible; it is possible for DFPL without 
recursion if data types are of bounded size (e.g. FORTRAN numbers and arrays). It is 


presumably possible to directly implement Rodriguez’s language in hardware also. 


At the same time as DFPL was developed, Dennis independently developed a Data 
Flow Procedure Language [Den-73] which is almost identical in terms of its primitive 
concepts. In its original form, it lacked an indeterminate primitive operator (present in 
DFPL) so that indeterminate programs could not be constructed. Further restrictions on 
the construction of programs in Dennis’ language were imposed to ease the mathemati- 
zation of the semantics. These restrictions also simplify direct execution by a data flow 
processor (hardware). Thus, certain semantic behaviors, permissible in our DFPL, were 


not allowed in Dennis’ original language. 


Of the four languages mentioned here (other than DFPL), only Dennis’ is having a 
denotational semantics developed for it. Stoy [Sto-74] and Ciccarelli [Cic-76] have 


mathematized the semantics of this language. 


A related class of programming languages is those conventional languages which 
include interprocess communication mechanisms. Examples of these are suggested by 
Hoare’s ‘“‘communicating sequential processes’’ [Hoa-78] and Kahn and MacQueen’s 
“‘coroutines and networks of parallel processes” [K&M-78]. Yet another kind of lan- 
guage related to data flow languages is LUCID of Ashcroft and Wadge [A&W-77]. This is 


a language which is applicative yet works on streams of data. 
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Background on Mathematical Semantics 


Kinds of Mathematical Semantics 


The two approaches to mathematical semantics are, as stated earlier, the axiomatic 
and the denotational or functional. In the axiomatic approach, each primitive operation 
in the programming language has associated with it one or more axioms which formally 
specify the effect the operation has on the state of the abstract machine when that 
operation is executed. That is, the axioms describe the mathematical relationship 
between the “‘before’”’ state and the ‘‘after” state. This relationship may or may not be 
functional. A sequence of operations have an effect which is the composition of the 
individual relations for the component operations. A loop in the program requires an 
inductive proof based on the relationship implied by the loop body and loop predicate. 
The inductive assumption (often called the loop invariant) may either be given or 
deduced from the initial and final conditions. A recursive program requires an inductive 


argument also. 


Programs which modify data structures as side effects are hard to deal with in any 
semantics. The usual axioms for assignment are not directly applicable when the 
assignment is to some computed variable. This situation arises with assignment to array 
components, with assignments indirectly via pointers, and with ‘“‘aliasing’’ of any data 
objects via procedure parameters. This remains one of the open problems in axiomatic 


semantics [C&O-78]. 


As is well known, programs which loop or recur sometimes do not terminate. 
Unfortunately, the inductive proof of a loop’s behavior mentioned above often does not 
prove termination, but only the behavior of the loop if it terminates. The termination 
property (often) must be proved as a separate result. A new axiomatic semantics called 
dynamic logic, which is based on modal logic (H&P-78], allows one to treat termination 
simultaneously with ‘“‘partial correctness’, (as the behavior assuming termination is 
frequently called). An extension to dynamic logic allows one to treat non-determinacy 
as well [H&P-78]. 
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. Thus, given a program together witli a:set of assertions abont its behavior, one might 
determine by theorem proving (manual or automatic) whether the program satisfies its 
assertions. Alternatively, one might derive an anserliog which ceseribes the prograth’ $ 
behavior. as a - Gin gE pag Se Ay BS - 


ae by associating oie baecedaent uae ke es @ ‘sequence of 


” operations computes the fesetion’ which te the eompusition of the component operations’ 
functions. If the operations are performed repeatedly; as:in’a WHILE loop,’ the compos- | 

- ite function is tot So easily determined: (iw the-ukiouanit iapproach, an inductive proof is 

meeiee): Setting. a eee: equation cofresponding to thr: loop, one: es: 


P(D)=If Test(X) Then F(Body(X)) Otherwise X_ 


where Test is the predicate of the WHILE, Body i is the function which describes the body 
of the loop, and F is the function which describes the Joop as a whole. This is a recur- 
sive definition, but it is hard to solve because the ‘unknown, F, isa fun unction. o 


This approach can be used on applicative languages with relative ease since such 
languages are ‘based on the ideas of functions and their” “composition. ‘Unfortunately, 
applicative languages are seldom ‘used ‘for programming: even LISP has ‘nonapplicative 
| operators such as GO, SETQ and RPLACD. “The effect ‘of sach ‘operators ‘is to ‘make the 


fevably from the syntactic 


functional characterization of the programa “depart ‘const 
“structure of the program. This occurs for two reasons. “First, ‘since s some operators such . 
as assignment (e.g. SETQ or worse, RPLACD) change the suite of the whole abstract 
‘machine, the function corresponding | to. such.an operator must transform states into 
states. Then, in order to be. composable, all Aperptars myst franstorm | states, whereas 
, the program is writsen as if most operators. trangforn |, Variables S.. _ Second, control flow 
_gperators: (of which LISP’s GO is a mild example) can cause = Poth, the. conditional and the“: 
.. loop structure of the program to become. rily complicated. | ‘Structured Program- 
ming, with its insistence on a limited, disciplined ; set of, sontrol ‘operators Ce. g. IF- THEN- 
ELSE and DO-WHILE) Prevents the second problem from occurring, that is, one recursive 
equation corresponds to one loop. The first. problem remains however, since most 


re ets 


.existing languages have state transforming assignment operators. 
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Mathematical Concepts 


_A partially ordered set, or poset, is a set of objects together with a relation which is 
reflexive, transitive and antisymmetric. That is, VX:X<X,VX,Y,Z:XSYAYSZeX 
$Z,and VX,Y:XSYAY<XX=#Y. If, in addition, the relation holds in one direction 
or the other for every pair of elements in the set, the set is said to be totally ordered. 
The integers are totally ordered under the usual ordering, while the set of all subsets of a 
given set are partially ordered under the inclusion relation. A chain is a totally ordered 
(subset of a) poset. A set is said to be pre-ordered or quasi-ordered under a relation if 
the relation is reflexive and transitive (but not antisymmetric). The set of equivalence 
classes under the quasi-order form a partially ordered set, where X and Y are in the 


same equivalence class iff XS YAY<X. 


A Cartesian product of posets is itself a poset under the pointwise partial order; that 
is, (Xa, Ya, Za) $ (Xb, Yb, Zb) iff Xas XbA Yas YOAZasSZb. Since a function can be 
treated as an element of a large cartesian product (the product of identical copies of the 
codomain indexed by the domain), functions can be partially ordered also. The order is 
defined by: F< G iff VX: F(X) ¢ G(X) 


An upper bound of a subset S of a poset P is an element U € P such that VX € S:X 
<U. A supremum or least upper bound (often abbreviated /.u.b.) of a subset S is an 
element L € P such that WU € P: L$ U where the U’s are upper bounds of S. An 
infimum or greatest lower bound (often abbreviated g./.b.) is the order duals of the 
above (which is obtained by replacing ‘‘$” by its converse relation ‘‘>”). Many posets 
of interest have a least element, called bottom (‘‘1’’), which forms a lower bound for all 
subsets. A Jattice is a poset in which every two elements have both an infimum or meer 
and a supremum or join [M&B-67]. Note that M is the meet of X and Y iff M<X and 
MSY and VB:BSXABS YBSM, and the join is the order dual. Many lattices of 


interest have both a least and a greatest element. 


A function from a poset to a poset is said to be isotone iff VX,Y:X < Y» F(X) s 
F(Y). (The term monotone is often used instead of isotone, but it is less precise since 


isotone corresponds to monotone increasing only [Ros-77]. ) 


A poset is said to be chain-com plete iff every chain has a supremum (not necessari- 


ly in the chain itself). The integers are not chain complete, for example, but the real 
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- numbers on.a closed interval are. Any chain complete poset necessarily has a bottom 

element — it is the supremum of the empty chain.. A. more. interesting. example of a 

_. chain complete poset is the set of all.fisite and infinite sequences. of elements of some 
set partially ordered by. the prefix or initial. subsequence. relation. . (For. example, AB < 

ABC $ABCD.andAB.SABD. ).Inthis poset, the suprema, are the. infinite sequences (length 


J a). The empty sequence is the Jeast element of. the entire. poset, but. there is no. _ greatest 


element. The paset.may-be pictured: as a tree. of infinite depth, where each (finite) node 

_ Sorresponds to. (finite) sequence, and.at.each.noda,:each arc Jeading away. from the 

_node.is labeled with.a different element from. the nadeciying set of objects. We. ‘restrict 
our attention to chains which are countable, whiohdees net sequire the. underlying set to 
be countable. For example, the set of subsets of the integers is uncountable, but the — 
chains under the iriclusion order each’ have a céuiitable nuftiber of elenients. Although 
there are other varieties of completeness, such | as directéd-set' ‘com pleteness' in which any 
finite subset which has an upper bound has a ‘suprentuii, ‘from sow on ‘we will mean 
“countable chain complete” whenever we aay —— ee i = 


A function from one complete poset to another i is said to be continuous iff it. is 
isotone and preserves ‘suprema; that i is, iff the value of the function on the supremum. of 
a chain i in its domain is the s supremum of thie set of values which is the image of that 
chain. Note that sirice the function i is isotone, it maps chains into chains. ‘Also, note 
that the isotonicity of the function can ‘be deduced. ‘from } its ‘continuity (suprema preser- 
. vation), merely by considering finite chains, whose suprema ‘are their greatest elements. 
Tris an easily proved and useful fact that a function ‘which’ maps a cartesian product of 
(complete) posets into a poset and is isotone ‘(continuous) on each argument is also 
isotone (continuous) on the tuple. "Similarly, : the” - composition of — wo isotone 
. (continuous) functions is in turn isotone (continuous). It is also’ Lhe to prove 
that the set of continuous functions from one ‘complete poset to another itself ‘forms a 
complete poset under the natural partial order. on fuactions. defined above. 


Now we come to the point of introducing posets, “completeness, isotonicity and 
continuity — the Tarski fixpoint theorem (Mar-76). if F: :P =P i is ‘an isotone function 
mapping a complete poset into itself, then F has.a least fixpoint Xi That is. 3X: F(X) =X 
and VY: F(Y)= YX s-¥,. Furthermore, if F is-cantinuons ax .well..a¢-isotone, we can 
“compute” its least fixpoint by a straightforward technique (actually the technique 
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” 


involves taking a limit, so it is not computable in the ordinary sense) [Sto-77]. Consider 
the sequence 1, F(1), Fi), F°(2), F*(.); etc. ‘This sequenee foriss: a chain ‘because 1 


fy 


‘S$ F(1) by definition of 1 and F(1)$ F!*'€1) beeatise * Foie visotone. . Therefore the .* 


sequence forms a chain which-has a limit or supremum ‘because. othe: poset vis: chain 
complete. If we form UFi(2) (where T€w), and call it x, _we see that X equals 
U,F(F/(1)) which by continuity equals FUP) J De which equals FD) ) a ‘fixpoint of F. 

_ To show X is the least fixpoint, assume Y isa fixpoint. ‘Then . s z and ‘thus ‘FW $s 
F(¥)=Y. So by induction, F'(1) s ¥ and so XS ce i | 


Denotational Semantics — 


In the standard treatments of denotational semantics one data element or function is 


., said to be less than another iff it is less well defined than the other, so that the partial 
orden is an ordering by approximation or information content [S&S-71]. Bor ‘example, in 


_ the. case gf partial functions one, may | be said t to be greater than another if it extends the 
other, that is, it is defined on a larger domain and they agree. in value on the smaller 

_ domain (Man-74], In the case of simple data, a “flat” partial order is often “used, it 
consists of a set of data which. are not order related to ch other a and a bottom element 
which is less. than any. true. datum. Such flat posets are not, of i interest in themselves, but 


__are used to construct more interesting posets as outlined. below. 


Earlier we indicated that it was difficult'to assign an! overnlt functional ‘behavior to 
programs with loops because a recursive equation results which has a function as the 
unknown. Such pauations, can be aa be ip. seortain ¢ circumstances s by means of the Y, or 
tapiagod such as LISP, B BCPL ee even ee ees wish o he an. to ‘treat, “fonctions as 
data objects. In order to mathematize this, we require that the domain ‘of functions 


- inélude functions fronr that ‘donhiifit to thatdowhiin: "This ateans that the domain must be — 


"recursively defined: If we let'N be the demain of’ W0trfunetional data’ (such .es num- 
bers), then the domain D must be tsotidrphit’ @°N GADD); the disjoint union of N 
“and the set of (Contittuous) functions from’ B’td'D:>'‘Stou's ‘contribution ‘has’ bean to 
show that there exist lattices culled reflexive. dottiaiiis WidGh satiety ‘this isomorphiam and 
in which the Y operator can always apply to give the tinique minimal fixed point solution 
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of the functional equations alluded to earlier. Furthermore, such domains adequately 


characterize programming languages. Thorough treatments of this approach to ‘program- 
. ming language semantics. may be found.in [M&S-76, Sto-77]. _ 


A slightly more recent approach to denotational semantics uses complete posets 
rather than complete lattices [ADi-77, Mar-76, ‘Ros-77). “Such posets accurately model 
the basic notion of approximation, and although ‘the ‘bottom: element corresponds to 


“undefinedness’’, the ‘“‘top” element of the lattice (and other “joins necessary for the ~ 


lattice to exist) do not seem to correspond to any computationally meaningful object. 
We do not use reflexive domains in this thesis, as we do. not, allow function valued data, 
but we do use posets rather than lattices, for the reasons stated. . 


Notation 


Names of variables and functions are denoted by capitalized cursive italic strda 
such as Var and Fun. This is more like programming notation than conventional 
mathematical notation, which tends to use single cliaracter symbols for all variables and 
functions, but it is more mnemonic and thus more readable when many names exist. 
Litera! data symbols are represented by austere italic letters such as A and by austere 
numbers such as 999. Literal data symbols may be tagged by appending strings of 
miniature digits to the symbols, for example, (Ao, Avo, Aoo1). 


The angle brackets ‘‘(” and ‘‘)’” are used to enclose explicit sequences of data, for 


example (4, B; C). Braces (i.e. “{” and “‘}”) denote sets in the usual way: {X,Y} 


denotes the set consisting of X and Y, ae {x | Ad denotes the set of all X 


. satisfying P(X). 


_ Subscripts on names denote selection of a particular item from a.set of similar items, 
for example Var,, Fun, Superscripts.on variables. which are streams. (sequences) 
. denote selection of an element from that. sequence, for example, 3,’ denotes the I-th 
element of the stream S,,, which in turn is the N-th stream of a set of related streams. 
Superscripts on data symbols mean repetition of that symbol, for example (A Ay denotes a 
sequence of K A’s. Superscripts on function names either denote repeated composition, 
if the superscripts are numeric constants or variables, or they denote a new function 


-27- 


related to that function denoted by the un-superscripted name, if the superscript is a 
greek letter. For example, F”(X) denotes the M fold application of F to X, whereas Fé 
denotes the ‘‘extension” of F by some rule, and F“ denotes the ‘‘completion” of F by 


some other rule. 


Finally, conventional mathematical notation is used for everything else: infix 
operators, prefix operators, quantifiers (with ‘‘:’’ separating the quantification from the 
body), function application and argument lists, and conditional expressions, including 
“Tf”, “Then” and ‘Otherwise’. 


£98. 
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Semantics of Determinate DFPL Programs 


Overview 


In this chapter we develop the fixed-point semantics of the determinate subset 
(really a sub-algebra) of DFPL. To do this we first show that the domain of Streams is 
suitable for fixed-point solutions of programs, then we show that the determinate 
operators are continuous on this domain. We therefore deduce that (recursion free) 
determinate DFPL programs have a well defined behavior no matter what inputs they 
receive. We conclude with an example of a simple fixed-point computation of a pro- 


gram containing a loop. 


A Complete Partial Order on Streams 


A Datum is an element of some set of data, for example, integers, characters, 
Booleans, arrays of floating point numbers, payroll records, directed graphs etc. The 
data sets available depend on the kind of DFPL programs being analyzed. We will not 
consider what types of data are available except that we shall assume that the integers 
are since they are needed to control the Switch operators. All data are assumed to be 
incomparable from the denotational point of view. That is, any ordering of data in a 
data set (e.g. the integers) is not of interest to us since it does not represent approxima- 


tion. 


A stream is a finite, empty or infinite sequence of data items, often denoted by 
enclosing their elements in angle brackets, for example, () for the empty stream, (A, B, 
C, D) for a finite stream of length 4,and(A,8B,...,2Z,...) for an infinite stream. More 
precisely, a stream is a function from the positive integers .or some initial segment 
thereof (including the empty set), to the set of Data. That is, S: Nseg ~ Data; where 
Nseg = { } (S the empty stream), or Nseg= {I | 1S I< N} (S a finite stream), or Nseg = {J 
| 121} (S an infinite stream). Put another way, streams are functions whose domains — 
are ordinals no bigger than w and whose codomains are some set Data. We denote the 
value of a stream at some integer I by S’ : using superscripting for emphasis. A stream 
S, is said to be a ‘“‘prefix’”’ of a stream S, (denoted S,<S,) iff Dom(S,) § Dom(S,) and S, 


“Bb: 


restricted to Dom(S,) (denoted.S, | Dom(S,)) is.equal to S,. That is, 3,7 -s/ for all I 
Dom(S,). 


Theorem 4.1: The prefix relation is a partial order on streams. 


Reflexivity and transitivity follow from the reflexivity ‘end: transitivity of ‘“‘s” and 
” especially “=. The antisymmetry of “¢" follows front ithe: anti4ymmetry of “5s”... 
Hence the set of streams form a discrete poset which sateen anee acae a 


Note that the bottom clement of this poset is the empty scream (denoted 4 or ©), and 
_ the infinite streams are maximal elements of the poset. 


Lemma 4.1: An indispensable property of Cpo-streams is the following: if S,, Ss, and 
S, are streams such that S, 45, and S, <5S,, then either 8,48, or S,€S,. This essen- | 
tially says that the graph of the partial order is a tree, with the empty stream as the root 
and the infinite streams as the leaves. _ caee pars: 


This follows easily from the fact that Dom(S,) and Dom(S, ) are ordinals so Dom(S,) 

& Dom(S,) or Dom(S, )s Dom(S, ). We apply the : definition of “¢" to get S, {Dom(S )~Sy 

and S,4Dom(S,) =S,, Now, assuming Dom(S,) © Dom(S, ), we get 8, {Dom(S,)= =S,{ 

_ Dom(S,){Dom(S,) which implies S, {Dom{S,)=8,, which means Ss, <5,. Assuming 
— Dom{S,) © Dom(S,) gives us S,¢S,, which proves the property. ga 


Lemma 4.2: If S, and S, are infinite, S, €S, iff 3,=S,. 
Theorem 4.2: The poset CRO ered is countable ata 


To show that this poset is chain complete, we must prove that any chain of ‘Streams 
has a supremum in the poset. The chains are just: sets. of streams, {Sy S,,.. 3, such that 
S,<S,<...; we need not worry that S,=S, since a chain i isa set. There are four cases 
to be considered: if the chain is empty, then its supremum is 1. If the chain | is finite, 
then its supremum is just its maximal element. If the chain is infinite and contains an 
infinite stream S, then S is the. supremum of the chain, since 8s8 and for all finite S, 8; 
<5, and for no finite S,, is S, 2 S, for all finite S,, and no other infinite stream can be in 
the chain. If the chain is infinite but contains only finite streams, then it its supremum S is 
not in the chain but does exist in the poset. We merely define s to be the stream such 
that S’=S,/ for all I € Dom(S,) for any S, in the chain. S is well defined because the 
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S, are elements of a chain. S is infinite because the chain is infinite and the domains 
Dow(S,,) are unbounded. No element of the chain is an upper bound (given any stream 


in the chain, we can find a longer one) so S is the supremum. f 


Therefore Cpo-streams lives up to its name: it is a chain complete partially ordered 
set. Note that the finite streams in this poset constitute a basis in the sense of [M&R-76]. 
‘Strictly speaking, we should define Cpo-streams(Data-type) and therefore have different 
posets for each kind of data. We will not do this in this dissertation, as the generaliza- 


tion is clear. Instead we will treat DFPL as an untyped language (like LISP). 


DFPL Operators as Isotone Functions on Finite Streams 


In this section, we restrict our attention to DFPL operators on finite streams because 


we wish to prove isotonicity — continuity is treated later. . 


The simple operators, since they operate on streams element by element, are clearly 
isotone. Let Sop, be a simple N -ary operator on streams which applies F to each 
N-tuple of corresponding input data. We denote this by Sop,(S,,...,S,): each function 


F gives a different simple operator. That is: 


Sop,(S,,...,S,)=S 


Where S'=F(S,',...,S,') 


VI éeL=N\,.y Dom(S,) 


JEN 


Now let S, €Sz,, then Sz, =() implies S, =() (because Dom(S,) S Dom(Sz,)). But Sz 
= Sopp(S,,...,Stx,...»Sy) iff for all J € Le= Dom(Sz,,M,,,-Dom(S,)) Sa! = F(S,",...,Sx,", 
99,7). Now since Ls La, it is also the case that for all J€ L: Sx’ =F(S,',...,Szy',..., 
S,‘). But since L s Dom(S,) and S, €Sz,, we have Sz’=F(S,’,...,S,") for all Je L. 


Thus Sz’ = S‘ for all 1€ Lso S€Sz. Therefore Sop is isotone in each argument. §J 
‘ 


The operator Hold takes a constant datum C and attaches it to the front of the stream 


S. We denote this by Hold,(S): each value of C gives rise to a different Hold function. 
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We define Hold (S)=C @S where “®” is defined as follows (with “+” representing 
ordifial addition): 


S@A#Sa 


Where Dom(Sa)=1 + Dom(S) 
And Sa! = If I=1 Then A Otherwise gt 


Thus “@” is isotone since if 3, <€S, then A@S,¢A@S;. Therefore Hold(S) is 


isotone in S. §] 


a9 


We define another useful isotone operation ‘‘r” as follows. (with “— 
ordinal subtraction): 


representing 


*S=Sd 
Where Dom (Sd) = Dom(S) —1 
And Sd! = Si+! 


Obviously, es is isotone since if S, <8, then 18, $18,. The “er” and a nepernnons 
are equivalent to CONS and CDR in LISP. se a 


The Switch operators are the most complicated functions from streams to streams. 
First we define the Outbound Switch operator Oswitch p(C, D): | 


Oswitch,(C,D)= 
If C=()VD=() Then () 
If C'=P Then D' © Oswitch,(1 C,1 D) 
Otherwise Oswitch,(1 C,1 D) 


Here P is the port number, C is the control stream and D is the data stream being 
switched. Thus an Outbound Switch with three perts (0, 1.and.2) would: require the 
three functions Oswitch,(C, oD Oswiteh (C,D) and mune D) for its complete 
a saan 


We prove that Oswitch is isotone in the argument C by showing that if Cs Cz then 
Oswitch ,(C, D) € Oswitch,(Cz,D). The proof. proceeds by induetion on the finite ordinal 
Dom(Gz). Note that Cz=() iff Dom(Cz) = { } and that Oswitch,(( ),D) = Oswiteh,(C, ()) 
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=) Substituting Cz in the definition of Oswitch, we get: 


Oswitch,(Cz,D)= 
If Czr=()VD=() Then () 
If Cz'=P Then D' © Oswitch, (1 Cz, 7 D) 
Otherwise Oswitch, (1 Cz,7 D) 


We assume in the steps that follow that D is not (),since for any C and Cz, Oswitch,(C, 
())=() = Oswitch (Cz, ()). The base step is as follows: Cr=() implies C=() so that 
Oswitch ,(C, D) = Oswitch (4 ), D) = Oswitch (Cz, D). The induction step is: let Dom(Cz) 
=N +1, if C=(), then Oswitch ,(C, D) = () which is a prefix of any stream. If C #() then 
tC €7Cz and C'=Cz!. Now if C'=P then: 


Oswitch,(C,D)=C' ® Oswitch,(1C,7 D) 


Oswitch,(Cz,D)=Cz' © Oswitch,(7 Cz, 7 D) 
So Oswitch, (Cz,D)=C' © Oswitch,(1 Cz,7 D) 


By the isotonicity of “®”, Oswttch (C, D) € Oswitch (Cz, D) if Oswitch (tC, TD) € 
Oswitch ,(tCxz, 7D) But tC €7Czx and Dom(tCzx) = N, so we may assume, as the inductive 


hypothesis, that Oswitch ,(1C, tD) € Oswitch ,(tCz, TD). Now if C' # P then: 


Oswitch,(C,D) = Oswitch, (1 C,7 D) 


Oswitch,(Cz,D) = Oswitch,(1 Cz, 7 D) 


But tC <7Cz and Dom(tCz)=N, so again we apply the inductive hypothesis, that 
Oswitch (tC, TD) € Oswitch ,(7Cz, TD). & 


The proof that Oswitch ,(C, D) is isotone in D is essentially identical. 


The Inbound Switch operator has N + 1 data ports D, through D,,, where we start at 
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0 because the simple case of D, and D, corresponds naturally to a True/ False Switch. 


Iswittch is defined as follows: 


Iswiteh(C,D,,....Dy)™ 
If C=() Then () 
If C'=0AD,#() Then 
D,' @ [switch (+ C,7 Dy,--.»Dy) 
If C'=NAD,#() Then 
Dy! @ [switch (1 C,Dy,.-.57 Dy) 
Otherwise ( ) 


One can prove that [switch is isotone in each of its argumentsin a manner similar to that 
Oswitch by which was proved isotone, except that the induction must be on the (ordinal) 


sum of the domains of the D, since only one is reduced by each recursion. 


DFPL Operators as Continuous Functions on C po-streams 


Having defined all the primitive determinate DFPL operators as functions on finite 
streams, we wish to complete them to be continuous functions on Cpo-streams. That is, 
we wish LIOp(C) = Op(LIC) for any chain C (where LIS denotes the supremum of S). 
This is straightforward since we have yet to say how a primitive operator transforms an 
infinite stream. Let Maz-chain(S)={S,|S,<¢S}for any S,so that for infinite S, 
Maz-chain(S) is the (infinite) maximal chain containing S. To make an_ operator 
continuous, we define Op*(S) = Op(S) when S is a finite stream, and. Op*(S)= 
LIOp(Maz-chain(S) — {S}) when S is an infinite stream (recall that if X is a set, F(X) = 
{F(Xelt) | Xelt € X}). 


Theorem 4.3: The completion Op” of Op as defined above is continuous. 


Since Cpo-streams is chain complete, the supremum _ exists. Since S= 
LJMaz-chain(S) we have continuity on maximal chains automatically. Now consider 
LJOp(C) where C is an arbitrary chain. There are two possibilities for C: it may contain 
a greatest element (if a finite stream then C is finite, if an infinite stream then C may be 


either finite or infinite); or C may contain no greatest element, (in which case it is an 
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infinite chain of finite streams). If C contains a greatest element S, then Op(S,)< 
Op*(S) for all S, € C (by isotonicity of Op* if S is finite; by definition of Op(3): for 
infinite S). Thus Op*(S) is the greatest element of Op*(C) and hence its supremum. 


If Cc contains no greatest clement, Cc will be an infinite subchain of Maz-chain(S) for: 
some infinite S. ‘Since Cpo-streams i is discrete and since Ci is infinite, no finite element i is 
an upper bound toz C, thus S=LIC. By definition of Op*(s) for infinite Ss, Op(S; « 
_ Op*(S) for all S,€ C. Now the set Op*(C) must be a chain because C is a chain and Op’ 
is isotone: If Op*€C).is an infinite chain then. it hag no finite, upper. bound so. it. has the 
(unique) infinite upper bound Op*(S). But there.are.no other upper bounds so Op*(S) = 
LIOp*(C). If Op*(C) is a finite. chain then it. has. a..greatest. element 3, = Liop*(C). By 
isotonicity of Op*, there must exist S, € C such that Op*(S,)=S,, for all S,2S, (obvious 
for S, € C, also true for S,€ Maz-chain(S)). Thus, S, = LIOp*(Maz-chain(S)) = Op*(S) = 

LIOp*(C). & fs, BF oe 


Therefore, we have proved that for any chain C, Op*(LiC) = LiOp"(C), so that. Op’ is 
continuous. This appli¢s in the obvious manner to: multirargumeat operators. . Note. that 
in the case of multi-agument operators the order of.taking-supreme does not matter 
because the operations of completing a poset.and- extending ‘an isotone function [Mar-76 
-‘Mar-77} give results unique up to isomorphism. .. 


Solvability of First Order Fixed-point Equations 


. We have now shown that the DFPL primitive operators are isotone on streams, and 
that we can extend any isotone function on streams to a Continuous function on streams 
by defining its behavior on infinite streams as above. ‘Thus’ DPPL’ primitive operators 
may all be extended to be continuous functiotis from streanis to streams, or more 
_ generally, from Cartesian proditcts of streams to" (Caitesian’ products of) streams. Now 
it is known that any system of equations involving’ ’ “only ‘continuous functions over 
maple posets have a minimal fixed point solution Mar, Mur- he 


Now any DFPL program sack that includes bali primitive operators and no recur- 
sion can be converted to an’equivalent system of équations. ‘ Recall that a program graph 
corresponds to a set of equations in which-each data path corresponds to an equation 
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variable and each operator instance to a function instance. By use of the copy rule, a 
program graph containing usages of defined operators can be expanded into a graph 
containing only primitives and thence into a (large) system of equations. Therefore, any 
such DFPL program has a minimal fixed point solution, that is, an assignment of streams 
to the data paths which are the overall result of “running” that program (perhaps 
forever) starting with empty data paths. 


Note that the solution obtained is a configuration of data streams and thus repre- 
sents a particular result of applying the function represented by the program, rather than 
the function itself. For this reason, we call this a first order fixed-point. 


Examples of First Order Fixed-points 


Figure 4.1 shows a simple DFPL program with a loop, for which we will compute a 
first order fixpoint. The Hold operator is as discussed earlier. TheEvery-other operator 
delivers as output every other element of its input stream: ‘For example Every-other((A ’ 
B,C,D,E,...) =A, C,£,...). We will not explore the innards af this operator, they are 
not germane to the fix-point computation. To solve this: loop, we ‘cut it at the point 
labeled X, then we solve the equation X = Every-other(Hold (Hold ,(X))). We do this 
by applying the standard fix-point rule, computing Ufa, F(1), FCF(1)),...}. 


Proceeding by this rule we start with Hold x )) = (A), Hold, ((A ))=(B, A) and X, = 
Every-other((B , A)) = (B). Note that this is the first approximation to x , not the first 
element of X which would be denoted X'. The second approximation is X, = 
Every-other(Hold (Hold ,(X,))) = Every-other(Hold , (Hold, (3) = Every-other((B , A, 
B))=(B, B). The third approximation is X,= Every-other(Hold, (Hold AX, » - 
Every-other(Hold (Hold ,((B , B)))) =. Every-other((B, A,B, B)=(B, B). Thus we 
have converged after three iterations (X =X,=X,). We can also derive the fix-point 
values of Y and Z. To wit, Y = Hold ,(X)= (A, B, B) and Z = Hold,(Y) m(B,A, B, B). 


We could equally well have cut the loop at Y or Z. Then we would have solved Y= 
Hold ,(Every-other(Hold,(Y))) or Z=Hold,(Hold ,(Every-other(Z))) respectively. 
Either of these approaches would have given the same results for X, Y and Z. 
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It is very important to remember that the iterations involved in computing a (first 
order) fix-point are not the same as the iterations implied by executing a DFPL program 
loop. In computing the fix-point, we are “standing outside of time” and considering the 
data streams as wholes, whereas in executing the program loop, we are observing the 
data streams develop within time. This is analogous to the solution of equations in 
physics: the iterations necessary to solve a dynamical equation do not take place within 
the time expressed by that equation. . 
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-5- 
-A Partial Order for Non-Determinacy 


Introduction 


We have seen that streams of data, partially ordered by the prefix relation, form a 
domain upon which determinate DFPL operators are continuous functions, so that the 
function computed by a DFPL program may be determined by means of function com- | 
position and computation of fixed-points. Our task now is to find a domain suitable to 
both determinate and non-determinate operators, that is, a domain in which both kinds 
of operators may be cast as continuous functions. Part of our task however, is to 
formulate the domain and functions in such a way as to be compatible with the determi- 
nate formulation. That is, there must be a morphism from the general system to the 
determinate one, mapping the determinate functions in the general system to corre- 
sponding functions in the determinate system, and mapping ‘“‘determinate” elements of 
the general domain onto corresponding streams in the determinate domain 


(Cpo-streams). 


Just as determinate DFPL programs may be viewed as functions on input streams and 
output streams, it is reasonable to view non-determinate programs as relations from 
input streams to output streams. Unfortunately, if we take this point of view, we lose 
the fixed-point theory which is based on continuous functions (although we still have a 
useful notion of composition for relations). The way out of this problem is to apply the 
well known ‘‘functor” which transforms relations on sets of objects into ‘‘equivalent”’ 
functions on sets of sets of those objects. Therefore, for the rest of this dissertation we 
shall characterize non-determinate programs as functions from sets of input streams to 
sets of output streams. Each stream in the set corresponds to one possible execution 
Each possible execution of a non-determinate program causes a particular stream, 
chosen from the set of streams, to appear on a particular data path. If the program is 
determinate, then only one stream can appear, so the set is a singleton. Thus the natural 
map between the determinate and non-determinate semantics involves mapping a stream 


to the singleton set containing that stream. 
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Counterexamples to ““Posets’’ on Simple Sets of Streams . 


The exact choice of what kind of set of streams, as we shall see, is crucial to the. 
formulation of a reasonable denotational semantics of DFPL. The obvious choice of a set 
of streams is just that, a set of streams. If we use this as our domain, the question is 
what partial order is suitable. The obvious choice for a partial order on sets is the 
inclusion relation, which i is even chain complete. A moments thought, ‘however, shows 
us that this is unsuitable j in that it does not reduce, when applied to singleton sets, to the — 
prefix order on streams. For example, the stream Avi isa prefix ‘of the streain a, B), : 
but the singleton set {(A)} is not a subset of the singleton ‘set due B iis “Thus: thy subset 
relation i is not a compatible partial order. 


To have a compatible partial order, the relation | becupen:, two. singleton sets of 
streams must reduce to the prefix relation on those two streams. The obvious extension 
of this to. non-singleton sets is to say that streams in the. first. set are matched with 4 
streams in the second and the first set is less than the. second iff the prefix relation holds 
on ail the. matehed streams. Furthermore, our intuition tells us thet one. set of streams 
can be ‘“*S” than another in two ways: first, as indicated above, the streams in one may 
be et of the streams in the other; second, the bieger set may simply contain more 
eesam. Coe 


‘This suggests the 2 following attempt ata partial order, a set of streams Ss, is is ‘“<$” | 
than a set Ss, iff for all streams S, in Ss,, there. exists a stream S, in Ss, such that S, isa 
prefix of S,. Unfortunately, this is not a partial order but only a quasi-order, since it 
does not obey the antisymmetry rule. Consider Ss, = {4), A, AYN ‘and Ss, == iM, AN 
Here we have both Ss, $ Ss, and Se, < Ss, but clearly Ss, #*Ss,. One way around. this 
difficulty is to form the equivalence classes of sets of streams which are both“‘<” and 
“>*? to one another. This constructs a “quotient” system’ in whith ““<’"ig guaranteed to 
be a true partial order. However, in this quotient. dottiain the semantic equations can 
only be solved to yield equivalence classes, (i.e. sets of “equivitent sets of streams) 


which might not be enough detail for our néeds. 


We now observe that the trouble with that previous alleged partial order was that it 
allowed us to match two different streams in Ss, with a single stream in Se,. Also, our 


intuition tells us that each element in a set of streams corresponds to a different execu- 


ahbe 


tion of the program, and since programs should be isotone functions, feeding a program 
a “bigger” input should not reduce the possible executions. That is, it should not be the 
case that {(A), (A, A)} < {(A)}. In response to these points, we make another attempt at 
a partial order: Ss, < Ss, iff there is an injective map from Ss, to Ss, such that each 
stream in Ss, is a prefix of its image in Ss,. Unfortunately, this too turns out to be only 
a quasi-order: consider the infinite sets Ss, = {(A), (4, 4,4), (4,4,4,4,A),...} and 
Ss,={(4,4),(4,4,4,4),(4,4,4,4,4,A4),...}. We can match (A) with (A, A), 
(A, A, A) with (4,A,A, A) etc., discovering that Ss, <Ss,, or we can match (A, 4, A) 
with (4, A), (4,4,4,A,A) with (4,4,A,A)etc. (omitting (A)) and find that Ss, 2 
Ss,. But this would imply that Ss, is equivalent to Ss,, which is unreasonable, since they 
have no elements in common. It does not help to demand that the map from one set of 
Streams to another be bijective, since then sets of unequal (finite) size would be incom- 


parable. 


The following scenario suggests that we wish Ss, to ‘be strictly less than Ss,. 
Consider a non-determinate program that operates as follows: it produces an indetermi- 
nate, but even (including zero), number of A’s on its output port, then copies its input 
symbols to that output port. Therefore, when presented with the input stream B, its 
output is (B) or (A, A, B) or (A, A,A,A, 8B) etc.; when presented with the input 
stream (A), its output is (A) or (A, A, A) or (A,A,A,A,A) etc.; and when presented 
with (A, A), its output is (4, A) or (A,A,A,A) or (4,4,A4,4,A,A) etc. More 
precisely, when applied to the input set {(A)}, it produces Ss, above, and when applied 
to the input set {(A , A)}, it produces.Ss,. Since our intuition tells us that the set {(A)} is 
strictly less than {(A , A)}, and since we wish all DFPL programs to be isotone, we must 


say that the output set Ss, is strictly less than Ss,, for they are clearly not equal. 
1 2 


. There are a number of other possible contenders for a partial order on sets of 
streams. One which actually is a partial order, and not merely a quasi-order, defines Ss, 
< Ss, iff there exists an injective map from Ss, to Ss, such that each element of Ss, is less 
than its image in Ss,, such that the image of the map is a closed below subset of Ss, (i.e. 
whenever X is in the subset, so are all Y ¢ X), and such that the map is co-isotone (i.e. 
F(X) < F(Y) implies X ¢ Y). Unfortunately, not all DFPL operators are isotone in this 
partial order, so it too is unsuitable for our purposes. In fact, we conjecture that there is 


no suitable partial order (if we restrict ourselves to plain sets of streams) which does not 
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require using equivalence classes of sets of streams, which reduces to the prefix order on 


singleton sets, and in which all primitive operators are isotone functions. 


Another Problem with Simple Sets of Streams 


Consider the DFPL program in Figure 5.1. It oonsists of two two-input Arbiter’s | 


‘whose outputs are connected to the inputs of.a simple. primitive Add. operator. If the 
input streams to the Arbiter’s are, as illustrated, the:singletons (2),.(3), <u) and (5), then 
the Arbiter’s outputs are the sets {(2, 3), (3, 2)} and {4, 5),(5, 4)}, which are also 
the inputs to the sides of the adder as shown. Now, since any determinate operator 
_ must, if confronted with sets of input streams, combine each stream eiement of each set 
| with every element of every other (i.e. it must operate on the Cartesian product of its. 
input sets) the output of the adder must be the set {(6, 8), (7, 7) (8, 5}. Note that 
the stream (7, 7) would be generated twice but would only Appear once, because the 
output is a ser. < 


Now consider the DFPL program in Figure 5.2. it consists of a single two input 
Arbiter whose output is connected ‘to both inputs of the. simple’ primitive Add Operator. If 
the input streams to the Arbiter are, as illustrated, the’ ‘singletons (2) and (3), then the 
Arbiter’s output is the set {(2, 3), (3, 2)}, which is also the input to both sides of the 
adder as shown. Now, by the Cartesian product rule we used above, the output of the 

adder would be {(4, 6), (5, 5), (6, 4)}. This, ‘unfortunately, is a result which the 
_ operational semantics of DFPL contradicts — the stream (5, 5) can never be a result of 
this program. The Arbiter either outputs (2, 3) or (3, 2), it can never output both 


together nor can it output their average! 


This example demonstrates that simple sets of streams is not an adequate basis for 
the denotational semantics of even very simple programs not involving fix-points. Such 
simple sets just do not contain enough information. to allow such Programs as Figure 5.1 
to be distinguished from programs like Figure 5. 2. In particular, the adder operator has 

no way of knowing whether its inputs came from the same or different Arbiter’s. Thus 
‘we feel justified in searching for a somewhat more complicated. basis. We must incorpo-— 


rate in each stream an indication of how it may have been arbitrated. 
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Sets of Tagged Streams of Data 


. It is possible to obtain a straightforward partial order by considering sets of tagged 
streams of data. Each datum in each stream in the set has associated with it zero or 
more tags, each of which identifies the sequence of arbitrary choices made by a non- 
determinate operator which contributed to the existence of that datum in that stream. 
Sets of tagged streams are constrained in the following two ways. A later datum may 
never be the result of fewer non-determinate choices than an earlier datum, and no 


Stream is merely an approximation to another. 


Two sets are compared by matching each stream in the first set with a stream in the 
second set such that the first stream is a prefix of the second stream. The prefix relation 
used here is the same as that used in Cpo-streams, except that the items in tagged-stream 
are pairs of Data and Tag-set, rather than merely Data. However, all the relevant 
properties apply to tagged-streams. This relation may be shown to be a true " partial 
ordering of sets of tagged streams, and the resulting poset is chain complete if infinite 


streams and sets are admitted. 


Each instance of an Arbiter ina DFPL program is uniquely identified by its 
Arbiter-name, an element of set with equality. Remember that each recursion level 
generates new instances of its operators. A Choice-sequence of an Arbiter is an empty, 
finite or infinite sequence of integers, chosen from range 0 through Number-of-input- 
ports—1. A Choice-sequence represents, in order, the non-determinate choices made by an 
Arbiter. A Tag is a pair (Arbiter-name, Choice-sequence), and represents the choices made 
by a particular Arbiter. A Tag-set is an empty or finite set of Tags such that no two 
elements have the same Arbiter-name component. A _ tag-set represents the non- 
determinate choices made by a set of Arbiters. The restriction that no two elements 
have the same Arbiter-name insures that no tag-set represents that an Arbiter has made, 
self-contradictory choices. A tag-set T's, is said to be an Extension of a tag-set Ts, iff 
there is an injective map from Ts, to Ts, such that for each element of Ts,, the Arbiter- 


name of that element is the same as the Arbiter-name of its image, and the Choice-sequence 
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of the element is a prefix of the Choice-sequence of its image. More precisely, we say 


that: 


TgsGTgszm 
IMap:Tgs + Tgsz: 
Injective( Map) A 
Vv T% €Tgs: 
Arbiter-name(Tg)= Arbiter-name ( Map ( Tg JA 
Chotce-sequence(Tg) <€ Choice-eequence ( Map: ( Tg)) 


A Datum is an element of some set of data. All data are assumed to be incomparable 
from the denotational point of view. A Togged-stream is” an empty, finite or infinite 
: sequence of pairs of the form (Datum, Tag-set) which obeys. ‘the tag-set extension rule. : 
This rule demands that the tag-set component of any ‘element in the tagged- “stream is an 
extension of the tag-set component of all elements preceding it in that. tagged-stream. 


This insures that no datum is the result of fewer n0n-determinate choices than a datum ae 


which occurred earlier in that tagged-stream. A Tagged-stream-set is anon-empty set of 

_ tagged-streams which is Prefiz-reduced. This means that no tagged-stream is a strict | 
. prefix of any other tagged-stream i in the tagged-stream-set. This insures that no tagged- 

stream is merely an approximation to another i in the same tagged- stream- set. 


- For example, the result of supplying a twe:port (non-determinate)- Arbiter. with, the 
(determinate) inputs {(A)} and {(3)} yields .as-output the. (aon-determinate) - tagged- - 

-stream-set {(Ao, Box), (B1, Aso)}, The result of passing. that’ set through a 
(determinate). operator. which throws away input data until an A. appears, whereupon it 
copies the rest of the stream to its output port, is {(Ao, Bos), (Aio)}. . 


The partial order on tagged-stream-sets may now ‘be , defined. A tagged-stream-set 
T's, is ¢ a tagged-stream-set Tae, iff there. exiets ‘an injective ™ map from Tis, ‘to Tss, 
such that each élément of Tss, isa prefix of its image in Tss,. ‘Note ‘that this implies 
that the cardinality of ‘Tess, is no bigger than that of T'ss,. Also note that this is equiva- 
lent to saying that Tss, 4 T'ss, iff for all elements of Tex,, there exists an element of Ts, 
of which it is a prefix. This may be shown as follows. If Sa, Sb and Sc are streams such. 
that Sa is a prefix of Se and So is a prefix of Se, then either Sa is a prefix of Sb or Sb is a 
prefix of So. This implies that if there exists an element S, of Tss, of which an element 
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Sa, of Tss, is a prefix, then there is no other element Sb, of T'ss, which is also a prefix 
of S,, otherwise, either Sb, would be a prefix of Sa, or vice versa, and we disallow this in 


the definition of tagged-stream-set. 


The map which takes a stream S into a tagged-stream-set 7'ss = {St} such that St’ = 
(S‘, { }) for all J € Dom(S), is an monomorphism of posets. This will become clear in the 
next two sections, justifying our implied claim of a non-determinate domain which is 
compatible with the domain Cpo-streams. We shall see later that the Tags have another 


use besides allowing the definition of a compatible partial order. 


The way that the tags force the tagged-streams of one tagged-stream-set to be 
compared with particular tagged-streams of the other tagged-stream-set is reminiscent of 
the ‘“‘arrows’’ in Lehman’s categories which he uses to model domains for non- 


deterministic fixed-point semantics [Leh-76]. 


Proof of Partial Order 
Theorem 5.1: The relation ‘“‘€’’ is a partial order. 


To prove that ‘‘§’’ is a partial order on tagged-stream-sets, we must prove that it is 
reflexive, transitive and antisymmetric. Reflexivity is obvious: take the identity map as 
the injection of Tss, to Tss,. Since any tagged-stream is a prefix of itself, we have Tss, 
STs. 


Transitivity is almost as simple. Given an injective map M , from Tss, to Tss,, and 
an injective map M, from T's, to Tss,, we know that the composition M,°M, is an 
injection from Ts, to Tss,. Then, since the prefix relation is transitive, we know that 
every element in 7'ss, is a prefix of its image (under M,°M,) in Tss,. Thus ‘“‘g” is 


transitive. 


Antisymmetry is the most difficult property to prove; it is the property which the 
alleged partial orders discussed earlier lack. Let M, be an injection from Tss, to Ts, 
and M, be an injection from Tss, to Tss,. We can immediately conclude that Tss, and 
Tss, have the same cardinality and that M, ° M, is a bijection from Tss, to itself. Each 


element of Tss, must be a prefix of its image in Tss, under M,°M,, but due to the 
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constraint on 1 tagged-stream-sets, no element can be a prefix of another. Hence the 
image must be the element itself so M, eM, must be the identity. Now we observe that 
each element of Ts, is a prefix of its image in Tse, under M,, + and that element in. Tse, 
isa oekis of its imagein Tes, under M,. But the image under M,:is the original element 
in. T'ss,, so the element in Tes, is equat to the element in Tes, by antisymmetry of the 
prefix relation. Therefore, Tss, is equal to Tsa,, and‘ it-antisymmetric. 


Proof of Completeness 
Theorem 5.2: The partial order “ “ag "ig (eueeabie? chain complete. 


. To prove this, we must show that any countable chain has.a supremum. Let {Tss, € 
Tss, 4 Tss,4...} be such a countable chain, and let-: 4M Mis} be the. associated 
sequence of injective maps which specify the relations (ic. M,:Tss, ~ Tss,, M;: Tes, ~ ) 
Tss, etc.). Let S be an element of Tesy, then the set’ {8)My (S),My° My +1)s.. .} 
forms a chain under the prefix order. Since Cpo-streams is chain Supleie this set has 
a supremum which we call S-sup. Call.the set of all such suprema. Tsa-sup. Since all 
the M’s are injective, and each 7'ss is prefix-reduced, we apply Lemma 4.1 to deduce 
that each element S of a T'ss belongs to éxactly one such chain. For each Tasy, define 
Msup, to map each element S into S-eup, the supremum of its chhin. The suprema of 
all distinct chains are themselves distinct (by Lemma 5.1 and the assumption that 7'ss’s | 
are prefix-reduced) because each chain has at least one non-supremal element not the 
other chain. Then we have that Msup,: Tes, + T's8-sup is an injective, map which 
establishes that T'ss, 4 Tss-sup. But N was arbitrary, so Tes-oup is an upper bound for 
the chain of 7'ss’s. 


If there were another upper bound, call it Tss-ub, for the chain of T'ss’s' which was 
strictly less than 7'ss-sup, then there would be an element S-ub in Tss-ud which was a 
strict prefix of an element S-sup of Tss-sup, or there would be an element in Tss-sup 

| which had no prefix i in Tss-ub. In the first case, S-ub would be an upper bound of some 
chain, but S-ub <S-sup, contradicting the fact that S-sup was ‘the supremum of that 
chain. In the second case, there would be a chain of elements from the Tss’ s which had 
no supremum in Ts8s-ub, hence Tss-ub could not even be an upper bound. Therefore, we 


may conclude that Tss-sup is indeed the supremum of the Tss’ s. 
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It remains to be shown that T'ss-sup satisfies the extra conditions on tagged-stream- 
sets: namely, that no tagged-stream is a strict prefix of another, and that within an 
tagged-stream, the Tag-set on a later item in the tagged-stream must extend the Tag-set 


on an earlier item. .We prove these additional properties by contradiction. 


If one tagged-stream, Ts,, were a strict prefix of another, 7's,, then all the elements 
of the chain of which Ts, was the supremum would be in the chain of Ts,, hence Ts, 


could not be their supremum. 


If the tag-set sxieasion property were not obeyed, then there would exist a tagged- 
stream Ts-sup in Tss-sup such that Tag-set(Ts-sup*) did not extend Tag-set(Ts-sup’) 
(where J $ K). But, since T'ss-sup is the supremum of its chain of T'ss’s, there would 
exist some 7'ss,, which contained a tagged-stream T's <T's-sup such that Ts’ = Ts-sup’ 


and Ts’ = Ts-sup” contradicting the tag-set extension property assumed for the 7's8’s. 


Therefore the Tss-sup is a proper tagged-stream-set and is the supremum of the 


Tss’s, which means that the set of tagged-stream-sets is a complete poset. {J 


Satisfaction of Previous Counterexamples 


As we have just proved, the set of tagged-stream-sets form a chain complete 
partially ordered set (not merely a quasi-ordered set). Also, we have shown how the set 
of tagged-stream-sets is compatible with streams under the map which takes a stream S 
into the singleton set consisting of the tagged-stream whose Data are the same as S, and 


whose tag-sets are empty. Therefore we have satisfied the two generic counterexamples. 


The specific counterexample involved a non-determinate program which had two 
states: produce A’s (state 0) and copy input (state 1). Using the history of these states 
as the Choice-sequence. attached to each output datum (and since there only need be one 
Arbiter, omitting the Arbiter-name and set brackets from the tag-set), we get the 


following specification of the program: an input of {(4)} gives rise to the output: 
{(A1), (Ao, Ao0o, A001) , (Ao, Avo, Aovo , Avovo , Acooor) ¢ 
whereas an input of {(4, A)} gives rise to the output: 


{(A1,A11), (Ao, Ao00,Aoo1 ,A0011) , (Ao, Avo , Avo 5 Aoooo , Av0001  Anooo11) ¢ 
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The rules for match tagged-streams in one tagged-stream-set with thote i in a another make 
it quite clear that the first output is 4 the second. 


Referring back to Figure-5.2 now, we see that the Ardtter'’s output streams would 
he tagged as follows: {(20, 301), (31, 210)}. Let us adopt a modified Cartesian prodygt 
tule, to be detailed i in the next chapter, that tuples of input streams are combined by an 
operator only if their Tags are Consistent. Then the output, of the adder would be the 
tagged-stream-set {(40, 601), (61, 410)}. The stream (5, 5) cannot appear at all in.the. 
' output set because its first clement would have to be tagged’ both 0. and 1. This is 
impossible: Since it would: nfedn that the Arbiter: ‘mde twee: maeaned exclusive decisions 


at once. ge 


In summation, we shave constructed. a domain for non-determinate Semantics that 
| satisfies all the objections we discovered to the earlier approaches. . 
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=Ge ; 
Semantics of Non-Determinate DFPL Programs 


Overview 


In this chapter we develop the fixed-point semantics of full DFPL with both the 
determinate and non-determinate primitives. We have shown, in Chapter 5, that the 
domain of Tagged-stream-sets is: suitable for fixed-point solutions of programs. We must 
now show that the DFPL operators are continuous on this domain. To do this, we first 
develop some helper functions on tag-sets, then we show how the determinate operators 
are extended to tagged-stream-sets, then we can show that the determinate operators are 
continuous. Next we precisely define the non-determinate Arbiter and prove that it is 
continuous also. We can therefore deduce that all (recursion free) DFPL programs have 
a well defined behavior no matter what inputs they receive. We conclude. with an | 
example of a simple fixed-point computation of a non-determinate program containing a Nees 


loop. 


Notation 


The notation used in this chapter is somewhat complicated and thus is outlined here. 
Variables are written out programming style (i.e. multi-letter abbreviations) as in earlier 
chapters, but there are more possibilities. Variables consist of a head (usually an 
abbreviation), which connotes their domain, an optional body followed by an optional 
tail, which identify the particular variable, and an optional subscript, which identifies 
one of a group of similar variables. Commonly appearing heads are: Ts for a tagged- 
stream, 7'se for a tagged-stream-set, Tg for a tag and Tgs for a tag-set. The common 
optional bodies are: -a-, -b-, -c- and. -d-, where -a- and -b- connote arbitrary distinct 
variables, -c- and -d- usually connote control and data inputs respectively, and lack of a 
body usually connotes an output variable. An tail -z usually connotes extension of a 
stream or set, that is T's < Tsx, Tgs & Tgsz etc. Some examples are: 7T'ss for an output 
tagged-stream-set, Tsdz, for the Jth extended data input tagged-stream, Tgsz for an 
extended tag-set, and 7'ga for an arbitrary tag. | 


“Si: 


In the interest of brevity, we often apply a function to a set of arguments without 
writing it out explicitly. For example, if F:X x Y + Z, we write F(Xs, Ys) (where Xs 
X and Ys¢& Y) instead of {F (Xa, Ya) | (Xa, Ya) € Xs x Ys}.. In general, if a function takes 
an element of some domain as an argument, we may apply that function to a set of such 
arguments implying that the appropriate set of results is denoted. Note that the original 
domain may have sets as elements, in which case we would apply the function to a set of 


such sets. 


Tag-set Functions and their Properties 


In order to define the extensions of the determinate operators (Hold‘, Sop’, 
Oswitch® and Iswitch*), we define some helpful auxiliary functions. First of all, we 
define some access functions which allow us to take components of Tagged-streams and 


Tags in a clear manner: 


Datum (Ts) = T's! 
Tag-set (Ts) = Ts? 
Arbiter-name = Tag! 


Choice-sequence = Tag? 


The next function, Consistent-tags, is a predicate which is true of unions of tag-sets 
which are consistent, that is, tag-sets which do not contain Tags with the same Arbiter- 
name but Choice-sequences which are not prefixes of each other (i.e. Choice-sequences 


which do not form a chain): 


Consistent-tags(Tgs,,...,Tgs,)* 
VTga,TgbeU 


Arbiter-name(Tga) = Arbiter-name(Tgb)»> 


I<N Tgs;: 


Choice-sequence ( Tga ) € Chotce-sequence (Tgb)V 
Choice-sequence ( Tga) > Choice-sequence (Tgb) 
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The last helpful auxiliary function is related'to the previous. It is. the Merge-tags 
function, which merges the Tags in a consistent tag-sét’ union to yield a tag-set which 
contains, for each Arbiter-name, the maximal ‘Choice-sequence from the input Tags: 


Merge-tage(Tgs,,...,Tg8y)= 
{T7 € Uy Tos, | 
VTga € Urcy T98;: 
Arbiter-name (Tg) = Arbiter-name a Ta )»> 
Choice-sequence (Ty) € Choice-cequence (Tga) } . 


‘The Merge-tags function is ‘used to generate the tag-sets for the oetpats of -opera- 
tors given their input tag-sets. The Consistent-tage function is used to. assure that. 
operators do not process any input streams which are inconsistent with each other (ef. 
Chapter 5, especially Figure 5.2 and related text). | . 


Lemma 6.1: Both Consistent-tags ae Merge-tags are commutative and associative 
functions. That is, F-tags(Tgsa, F-tags(Tyab, Tgsc}).= P-tags(Tgsa, T9sb, Tgsc)= 
F-tags(T gsc, F-tags(Tgsa, Tgad)) = (where F-toge i is Consistent-tage or. Merge-tags). 


This follows directly from the definitions. 


Lemma 6.2: If Tgs G Tysz then Consistent-tage(Tgs, Tyan) is True. This too follows 
directly from the definitions of “GS” and Consistent-tags. | 


Lemma 6.3: If Consistent-taga(T ye, ..sT 98s ---s tes, is False, then for any I and 
any. Tysz, such that Tgs,G Tgsz,, Consistent-tags(Tgs.,, 4 9 Tys2y .. = Tg8y) is also False. 
Expanding the definition of Consistent-tage(Tys,, .. a Tp - “ Ts,) we find that it is 
False iff: | | | 


3Tga,Tgb € Usen Tgs,: a 
Arbiter-name (Tyga) = Arbiter-name(T9b)A. 
Choice-sequence ( Tga) ¢ Choice-sequence(Tgb) A 


Chotce-sequence( Tga) & Choice-sequence(Tgb) © 
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Now recall the definition of ‘&’’: 


Tgs,& Tgsx,3 
iMap:Tgs, > Tgsz,: 
Injective (Map) A 
VTq € Tgs,: 
Arbiter-name (Tg) = Arbiter-name(Map(Tg))}A 
Choice-sequence (Tg ) € Choice-sequence (Map(Tq)) 


Now if neither the Tga or the Tgb which falsified Consistent-tags(Tgs,,...,793,5..-5 
Tgs,) is an element of Tgs,, then Consistent-tags(Tgs,,...,Tgsz,,...,Tgs,) is trivially 
False also. If, however, either Tga or Tgd is an element of Tgs, then its image in Tgsz, 
under Map serves as a counterexample to Consistent-tags(Tgs,,..., Tgsz,,...,Tg8y) (due 


to the properties of ‘‘<€’’). 


Lemma 6.3 assures that the tagged-streams which result from the operators defined 
recursively in the next section are well behaved in the sense that if the recursion is 
terminated by Consistent-tags(...) becoming False, there are no elements farther down 
some input stream which might contribute to the output, if only they could be reached. 


That is, the recursive definitions do not disallow any realizable behavior. 


Lemma6.4: If Tgsz,&Tgs, then Merge-tags(Tgs,,...,Tg8))....Tg8y) & 
Merge-tags(Tgs,,...,Tgsx,,....Tg8,). Recalling that: 


Merge-tags(Tgs,,...,Tg8,,....T98y)™ 
{Tg € Usen T98, | 
VTga € Use Tgs,: 
Arbiter-name (Tg) = Arbiter-name(Tga) > 
Choice-sequence (Tg) ¢ Choice-sequence(Tga) }. 


We immediately derive that: 


Merge-tags(Tgs,,...,Tgsz,,...,Tg8,)™ 
{Tgx € Tgs,UU,,, Tgs, | 
VTga € Tgs,UU,,, T98,: 
Arbiter-name(Tgz) = Arbiter-name(Tga) > 


Choice-sequence (Tgxz) € Choice-sequence(Tga) } 
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Let Mtg = Merge-tags(Tgs,,...,Tgs,,....Tg8,) and Mtgz = Merge-tags(Tgs,,... »Tg8tp.... 
Tgs wy): To show that Mtg Mtgz we must construct a map M tmap: Me tg + Mtgz which 
satisfies the definition of “G” above. Let Tg € Mtg, Tgz€ M tga and Tos = M: tmap(TQ). 
Now define Mtmap as follows, if Tg € Tgs, where J #1, then Toe = T9, but if Tg € Tys, 
then Tgz = Map(Tg) where Map is the map which makes T 98, A & Tosa 7 a8 above. 
Obviously Mtmap satisfies the second (quantified) part of the definition of “G” s 

both Map and the identity do, so we only need show that Mimap is injective. Let Tyga # 
 Tgbd be arbitrary elements of Mig and let Taz and Tote be their images: under Mtmap.: 


Note that neither Tya ¢T9b nor Tyb < Tya can be'true beca ase of the definition of Mtg. 


If neither Tga nor Tyb aré in Tys, then Tyas = Tya and Tybe= Tyb so Tyax # Tybe since. 
Mtmap is the identity except on gs). Similarly, if both Tyo and: fy ‘are’ in Pysx,, then 
Tgaze Tybds because Mtmap = Map when restricted to Tyee, and Mapi is assumed injective. 
The interesting cases:ase when Tyga € Tga,.and. Tob Ts, ar vice-versa. In. the. first 
case, Tota = Tgb and Tgaz = Map(Tga). But by the assumption that Map shows tow 
Tys,G Tgez,, we know that Chovice-eequencel Ta) ¢ Choice-sequence(Tga2).. By the 
properties of ‘‘<” and sequences, and by the fact that Tga¢Tgb.and Tyb¢ Tya, we see 
that Tgb * Tgaz and hence that Tgbz * Tgas. Therefore Mimap is. injective and Mtg S 
Migz. 


Lemma6.5: If Tgs& Tgsx. then Merge-tags(Tgs, Tgex) = Tgsz. Substituting in the 
definition of Merge-tags, we get: 


Merge-tags(Tgs,Tgsz) = 
{Tg € TgsUTgsz | 
VTga € TgsUTgsz: 
Arbiter-name ( Tg) = Arbiter-name (Tyga » 
Choice-sequence (Tg) 4 Choice-sequence ( Tga) }- 


lf Tg € Tgs then 3T gz € Tgsx: Tg < Tgx (because Tgs c Tgs2) so no elements of Tgs 
contribute themselves to Merge-tags(Tgs, Tgsx} unless they also are in a Tosz. Therefore 
Merge-tags(Tgs, Tgsz) = Tysz. & 


Lemma 6.6: If Cine tag dtien Tgsb) then Tysa & Merge-tags(Tgsa, Tgsb), and 
symmetrically, Tgsb © Merge-tags(Tgsa, Tgsb). 
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Consider all pairs (Tyga, Tgb) € Tgsa x Tysb. If  Arbiter-name(Tga) # 
Arbiter-name(Tgb) then both get included in Merge-tags(Tysa, Tysd). if 
Arbiter-name(Tga) = Arbiter-name(Tgb) then the’ one that is the prefix of the other (and 
one is since the sets are consistent) gets. discarded in» ‘the:-- construction of 
Merge-taga(Tgsa, Tgsb). Since both Tysa and Tgab have only one occurrence of each 


Arbiter-name, we can stop after, considering ach pair, no further prefixing con obtain. 
Hence each Tgo either itself appears in 1 Merge-tage(T yea, 1 Taq) or a Ty of which it is a 
prefix appears. Therefore, by the definition of “G”, we see ‘that TgeaG 
- Merge-tay Tysa; Pgs} and symmetrically..eo 


Extension of Determinate Operators. 


whe be ’ 
SBR oe 


The Hold opérator is the’ ‘iptor meet “to issairunel ‘to asmerane It. is 
vf defined as follows: See Teh 


= Holdf (Tss ): ws f Tso € for Tes) | on esta sh: “eg 4Td} 


Where Hold o(t)= 
“If Dom (te Then Hold, (TeV oeneratss Uren eee, 


jpey is 


_ Where.Hold, (T= (6,1): Ts. 


‘That is; Hotd fC Paayte the wet of ail taggéc-streams ‘from T'sa with. the additional item 


“empty-tagged: C” attached to the ‘front, ‘asd: the resulting: ‘set is:reduced to: eliminate 


- strict prefixes. “But since Tes is. already: on ee the extension of “@” 


is trivial, we can simplity the definition to: drape. 


Hold cf(Tes)= {(C, {Hors ' Tee Te} 


‘Note that since any tag-set extends the empty bows the tagged-streams in Hold o'(Tss) 


obey the tag-set extension rule. Note also that the unertinded ‘Hold ‘function ‘bere i is 
very similar to the Hold fonction in Chapter 4: 


To simplify the definitions a ‘i remaining DFPL Goetuiors. » we define once and for 
all the completion Op* of an operator Op. Namely: 


Op*(...,78,,...5T8y)= LI Op(Ca( Ts, ),...,Ca(Ts,)) 
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Where Cs(Ts)= 
If Dom(Ts)<w Then {Ts} 
Otherwise {Tea | Tsa<€Ts} 


7 This definition is the obvious generalization of the one ‘used above in the detitition of 


Hold, “ and is equivalent to the definition used i in hires 4. 


Lemma 6.7: The completion Op* of an isotone operator . eee as Aefined above, is 


continuous on its Tagged-stream arguments. 
is 


The single “LJ” is well defined because the codomain of Opis the set Tagged- 
streams.which is w-chain complete and the set Qp{Cs(Ts,), ....Ca(Ts,,)) is directed and of 
cardinality no bigger than w [Mar-76, Mar-77].. The proof is thus the obvious generaliza- 
tion of the proof of Theorem 4.3, substituting directed sets : fer chains and the domain 
ere for Cpo-streame. 


Now we can define the extended Simple Operators. The extended Simple Operator 
Sop,* rp of N arguments and one parameter F (the function to be applied), essentially 
takes the Cartesian product of its input tagged-stream-sets and applies the stream 
operator Sop, to each element thereof to get an output .tagged-stream-set, from which 
strict prefixes are eliminated (Pre fiz-reduction). However,-.whenever Sop, finds | 
tag-sets which are mutuaily inconsistent, it ceases. processing that particular N-tuple of 
input streams, truncating the output stream. accordingly. This insures. that F is ‘not 
applied to any data which could not coexist under a particular sequence of non- 


determinate choices. The precise definitions of Sop,é and Sop, are: 


Sop,(Tes,,...,788y)= 
{ Tsa € Sop,*(Tss,,...,T8s,,) | 
V Tsb € Sop,°(Tss,,...,T88,):Tsa #Tsb } 
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Where Sop,(Ts,,...,Ts,) = 
If JIS N:Ts,=() Then () 
If Consistent-tags (Tag-set(Ts,'),...,Tag-set(Ts,')) Then 
(F (Datum (Ts,'),...,Datum(Ts,')), 
Merge-tags(Tag-set(Ts,'),..., Tag-set(Ts,')))® 
Sop,(1 Ts,,...,7 Tsy) 
Otherwise ( ) 


Next we define the extended Outbound Switch operator. The Oswitch ,§ operator 
takes two arguments: the control tagged-stream-set, Tssc, the data tagged-stream-set, 
Tssd, and one parameter, the port number P. This parameter is necessary since the 
Outbound Switch is an N output operator, and mathematical notation does not directly 
allow such functions. Oswitch ,§ essentially applies Oswitch, to each pair of input 
tagged-streams in the input tagged-stream-sets, and then Prefiz-reduces the resulting 
set. Again, Oswitch, stops processing its input streams whenever it finds two tag-sets 


which are inconsistent. The precise definitions of Oswitch,* and Oswitch, are: 


Oswitch »*(Tssc, Tssd) = 
{ Tsa € Oswitch,*(Tssc,Tssd) | V Tab € Oswitch,” ( Tesc, Tesd): Tsa 4 Tsb } 


Where Oswitch ,(Tsc,Tsd) = 

If Tsc=()VTsd=() Then () 

If Datum (Tsc') = PA Consistent-tags ( Tag-set ( Tsc'), Tag-set (Tsd')) Then 
{Datum (T'sd'), Merge-tags ( Tag-set (Tsc'), Tag-set(Tsd'))) ® 
Oswitch,(T Tac, Tsd) 

If Datum (Tsc') # PA Consistent-tags ( Tag-set (Tsc!), Tag-set(Tsd')) Then 
Oswitch,(7 Tse, Tsd): 

Otherwise ( } 


Last we define the extended Inbound Switch operator. The /switch® operator takes 
N +2 arguments: the control tagged-stream-set, Tsse, and N+1 data tagged-stream-sets, 
Tss,. I switch* applies Iswitch to each N + 2-tuple from the Cartesian product of its inputs 
sets. Iswitch stops when it finds tag-sets which are not consistent, as usual, but note that 


Iswitch recurs differently than the previous operators; although it always takes “‘r” of T'sc 
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(the control tagged-stream), it only takes ‘‘r” of the selected data tagged-stream, Ts,. 
The precise definitions of Iswitch® and Iswitch are: aa 


Iswitch® (Teac, T88,,..-»T88,)™ 
{ Tsa € Iswitch® (No-tags , Tssc,Tss,,...,Ts8,,) | 
V Tsb € Iswitch® (No-tags , Tssc,Tss,,...,T88,,): Tea €T8b } 


Where No-tags = { iz 


And Iswitch(Tgs,Tsc,Ts,,...,T8,)™ 
If Tsc=() Then() 
If Datum(Tsc,)=OATs, =() Then) 
If Datum (Tsc,)=NATs,=() Then() 
If Datum (Tse, )=0A Consistent-tags(Tys, Tag-set (Tsc') , Tag-set ( Ts,! )) Then . 
(Datum (Ts,'),Merge-tags(Tgs, Tag-set (T'sc!), Tag-set(Ts,'))) © 
Iswitch (Merge-tags (Tys, Tag-set (Tsc!), Tag-eet Ts,')), 
7 Tsc,7 Ts,,...,T8y) 
If Datum (Tsc,)= N A Consistent-tags (Ts , Tag-set ( Tsc') , Tag-set(Ts,')) Then 
(Datum (Ts,,'),Merge-tags (9s, Tag-set (Tee'), Tag-set (Ts,,'}))@ 
Iswitch (Merge-tags (Tgs , Tag-set (Tsc'), Tag-set(Ts,,')), | 
t Tsc,Ts,,...,7 T8y) . 
Otherwise () | 


Continuity of the Determinate Operators 


Theorem 6.1: The extensions of determinate operators, as defined above, are 
continuous functions in all of their tagged-stream-set arguments. 


Let F* be a function on tagged-streams which is continuous and thus isotone, and 
let {Tss,, Tas, ...,; 78s} be a chain whose supremum is 7ss. (Although F may be a 
function of several arguments, we are considering continuity in one. argument at a time 
so for brevity we elide the others and write only F(X).) Consider the sequence of image 
sets: {F°(7'ss,), F“(7'ss,), ...,F“(T'ss)}; note that this is not the extension of F” as above, 
just the normal application of a function to a set of arguments. If {Ts ie TS yjseery T8h, 
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a 


where Ts, € Tss,, is a chain whose supremum is Ts, then {F°(Ts,), F“(Ts,,1)s e208 
F°(Ts)} is a chain whose supremum is F“(7's). (We start the chain with K instead of 1 


because the cardinality | Tss_| is isotone in J and hence not all possible chains start in 


_ Tss,.) But, although F°(7's_) € F°(Tss,), itis not necessarily the case that F“(Ts,) € 


F*(Tss,) because F*(7'ss p is the Pre fiz-reduction of F*(Tss,). However, if F“(Ts,) € 
F*(Tss,). then F*(Ts,,,)¢€F(Tss,,,). because F°(Ts,) € F*(Tss,) means that for all 
F°(Tsa,) € F*(Tss ,): F*(Ts,) #F°(Tsa,) and F*(Tsa,)€F°(Ts,). But then Ts,<Ts,,, . 
and Tsa, < Tsa,,, taken together imply that F“(Ts,)<¥F“(Ts,,,) and that F°(Tsa,)< 
F“(Tsa,,,).. Thus F(Ts,, )€F°(Tsa,,,) and F*(Tsa,, )¢F(Ts,,,) by Lemma 4.1. 

Therefore, every chain of F°(Ts,) (an element of F“(T7'ss,)) has a closed-above subchain 
F(Ts,,, 
thereby establishes the necessary w+1 sequence of injections from F*(Tss,) to 
F(Tss,,,) and on to F*(7'ss). This proves that {F*(Tss,), F*(Tss,),...,.F"(Tss)} is a 


chain and F*(7ss) is its supremum. &] 


) (an element of F*(Ts I> p) which is disjoint from all other such chains and 


‘ 


Theorem 6.2: The extended operator Hold* is continuous. 


The continuity of Holdé follows easily from Theorem 6.1; we merely observe that 
‘*®” is isotone on streams. Note that our results in Chapter 4 concerning streams carry 
over to tagged-streams, since the pairs (Datum, Tag-set) make perfectly good stream 
elements, that is, the codomain of a stream function may be any set with an equality 
relation. The only care we must take is to show that our resultant tagged-streams obey 
the tag-set extension rule. It is clear that a tagged-stream whose first element has an 
empty tag-set obeys the tag-set extension rule if the remainder of the tagged-stream 


obeys the rule, which it does by assumption, being the input. 6 
Theorem 6.3: The extended operator Sop‘ is continuous in all of its arguments. 


To show that Sop‘ is continuous on tagged-stream-sets, we first note that Sop‘ is an 
extension of Sop’, which obeys the precondition of Theorem 6.1, because Sop” is the 
continuous completion of Sop (by Lemma 6.7) if Sop is isotone. So we need only prove 
that Sop is isotone on tagged-streams. We prove that Sop is isotone in its I-th (Data- 
path) argument by showing that if Ts,<Tsx, then Sop ATs, scuad 8 yy vine Ts) € 
Sop,(Ts,,..-, T8z,,....T8,) . The proof proceeds by induction on the finite ordinal 
Dom(Tsz,)=N; note that Tsz,=() iff Dom(Tsz,)={}, and that Sop,(Ts,,...,(),...5 
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Ts,,)=() for any 1<$J<N. Substituting Tsz, in the definition of Sop,(Ts,,...,Ts,,..., 


Ts,,), we get: 


Sop,(Ts,,Tsz,,Tsy)= 

If Tea,=() Then () 

If AJ #1: Ts,=4) Then () 

If Consistent-tags ( Tag-set(Ts,'), Tag-set (Tsz,), Tag-set Ts,')) Then 
(F (Datum (Ts,'), Datum (Tsz,),Datum(Ts,')), 

Merge-tags ( Tag-set(Ts,'), Tag-set({ Tsx,'), Tag-set(T's,')))® 

Sop,(1 Ts,,7 Tsz,,7 Ts,) 

Otherwise ( ) 


We assume in the steps that follow that V1 <I < N:Ts,%(),since otherwise Sop ,(T'8,5-.-5 
Ts ,,....T'8y)*(). The base step is: Tsz,=() implies Ts; =() so that Sop,(Ts,,...,Ts,, 
Tay) = () = Sop,(Ts,,...,T8z,)...5T8y), The iaduction step is: let Dom(Tsz,) = N + 
1. if Ts,=\ ), then Sop,(T,, ..., T8,,....T8y) =(), which is the prefix of any tagged- 
_ stream. If Ts,#(), then Ts,'=Tsx,' and 1Ts,<€tTsz, Now if. Tag-set(T's,') is not 
consistent with some Tag-set(Ts,'), then Sop,(Ts,, .. Thy. 9 Ty) =(), which is the 
prefix of any tagged-stream. Now if Tag-set(Ts,') i is consistent with all Tag-set(T's yds. 


Sop,(Ts,,....T8,5...,T8y) = 
(F (Datum (Ts,' ),...,Datum(Ts,'),...,Datum(Ts,')), 
Merge-tags(Tag-set(Ts,'),...,Tag-set(Ts,'),...,Tag-set (Ts,')))@ 
Sop,(7 Ts, Sc T8,,...,7 T8y) 


Sop, (Ts, ,...,T8z,5...,T8y) = 
(F(Datum(Ts,'),...,Datum(Ts,'),.. |, Datum (Tay), 
Merge-tags(Tag-set(Ts,'),..., Tag-set(T's,! yieee: ,Tag-eet (Tsy')))® 
Sop, (7 Ts,,...57 Taz,,...,7 T8y) 


Sop,(T8,,...,T8t,,...5T8,)™ 
(F(Datum(Ts,'),...,Datum(Ts,'),...,Datum(Ts,')), 
Merge-tags (Tag-set(Ts,'),...,Tag-set(Ts,'),... -»Pag-set (Ts yy) ® 
Sop, (7 Ts,,...,7 Tsz,,...,7 T8,) 
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Hence, by the isotonicity of ‘‘®’’ we deduce that Sop,(Ts,, swag Ts now T's y) < Sop,(7s,, 
...9 T8%,,...,T8y) given the inductive hypothesis, that Sop,(TTs,,...,.7Ts,,...,TT8y) € 
Sop (TTS, ...,TT82,...,TT8y) - This is the inductive hypothesis because r7'sz,€TTs, 
and Dom(tTsz,) =N. , 


Next we must show that the tagged-stream which results is indeed a proper one 
which obeys the tag-set extension rule. To do this we apply Lemma 6.4. Assume /<K, 
and let Ts” and Ts* be the J-th and K-th elements in the tagged-stream output of 
Sop,(Ts,,...,T8,,...,T8,). Also assume that all its inputs 7's, obey the tag-set extension 
rule. By unwinding the recursive definition of Sop, we see that Tag-set(T's’) = 
Merge-tags(Tag-set(Ts,”), ..., Tag-set(T's,,”)) and the same for K. Thus we can easily 
see that 7's obeys the tag-set extension rule — refer to the above equations for 
Tag-set(Ts”) and Tag-set(Ts*) and note that the inputs Ts, obey the tag-set extension 
rule (Tag-set(Ts,") & Tag-set(Ts,*) for all I). Therefore since each application of Sop 
obeys the rule we conclude that Sop obeys the tag-set extension rule as well as being 
isotone. &] 


Theorem 6.4: The extended operator Oswitch* is continuous in both of its arguments. 


Again we prove this by first proving that Oswitch is isotone on tagged-streams, then 
appealing to Lemma 6.7 and Theorem 6.1. We prove that Oswitch, is isotone in its first 

| argument by showing that if T'sc < Tscx then Oswitch p(T'se, Tad) € Oswitch p(Tscz, Tsd). 
The proof again proceeds by induction on the finite ordinal Dom(7'scz)=N ; Note that 
Tscex=() iff Dom(Tscx) = { } and that Oswitch p(( ), Ted) ={ ) = Oswitch ,(T'sc,()). Substi- 


tuting Tscz in the definition of Oswitch,, we get: 


Oswitch ,(Tscx, Tsd) = 
If Tscz ={)V Tad =() Then( ) 
If Datum (Tscx') = P A Consistent-tags ( Tag-set (Tscz'), Tag-set(T'sd')) Then 
(Datum ( Tsd'), Merge-tags ( Tag-set ( Tscxz') , Tag-set (Tsd')}) @ 
Oswitch, (1 Tscx, 7 Tsd) 
If Datum (Tscz!) # PA Consistent-tags ( Tag-set (Tscx!), Tag-set(Tsd')) Then 
Oswitch, (7 Tsez, 7 Tsd) 


Otherwise () 
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We assume in the steps that follow that Tsd # (), since for any Tse and T scx, 

| Onwttch, (Tsc,{ )) = ( ) = Oowiteh (Tez, ( »). The base step is: Tscx =() implies Tsc=() 
to that Oswitch p(T sc, Tad) = Oswitch pO), Tsd) = Oswiteh p(T'scz, Tsd). The inductioti 
step is: let Dom(Tscz)=N +1. If Tsc =(), then Oswitch,(Tsc, Tsd) a ), which is the 
prefix of any tagged-stream. If Tec #(), then. Tee! Teez! aitd-+Tse ¢ Tacx. Now if 
Tag-set(T'sc') is not consistent: with: Tag-set( Ted"), then Onwitch( Te, Tsd) = (), which is 
the prefix of any tagged-stream. But if fog ante is consistent ‘with Tag-ver(Tad'), 
and Datum(Tsc') # P then: 


Oswitch (Tec, Ted) = Oewitch (1 Tec, 7 Tad) 
Oewitch, (Tacx, Ted) = Oswitoh, (17 Tacx, t Ted) 


Hence, since Dom(7T ez) =N and rTsc ¢ rTecs, we ‘may assume the induction hypothe- 7 
sis, that Oswitch p(t Tee, 1 Tad) € Oswitch y (rece, +Tad). it however Tag-aet( Tec!) is . 
consistent with Tag-set(Ted'), and Datum(Tsc!) = =Pthen: ee 


Oswitch, (Tac, Ted) = 
(Datum (Tsd'), Merge-tags (Tag-set (Tec!) , Tag-set(Tad")))@- 
Oswitch (1 Tac, Ted) 


‘Oswitch, (Tecz, Tsd) = 
(Datum (Tsd'), Merge-tags ( Tag-set ( Tees! ), edad t Ted ' 2 ) ) ® 
Oswitch ( 7 Tscz,7 Ted) 


So Oswitch,(Tsex,Tad)= 
(Datum (Tsd'), Merge-tags ( Tag-set ( Tsc! 7 Tag-set ait Ped »)® 
Oswitch, (7 Tsez,7 Td) 


Hence, by isotonicity of “@®” we deduce that Oswitch ,{7'se, T'sd) < Oewitch ,(Tscz, Ted) 
given the induction hypothesis, that Oswiteh At Tac, TT ed} Soe ent soe TT'sd). 


Now we must show that Oswitch obeys the tag-set extension rule. Again we apply 
Lemma 6.4, this time to the tagged-stream output of Oswitch ,. Assume Jout $ Kout, 
and let Ts’ and Ts*™t be the Jout-th and Kout-th elements of Oswitch,(T'sc, Tsd). 
Note however that T's¥t does not necessarily derive from Tsc*™* and T'sd*“t because 


the recursion schema skips elements of the input tagged-stream (i.e. whenever 
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| Lemma 6.7 and Theorem : D. 


= ae 
Datum(Tsct)# P). But Tag-set(Ts*™) = Merge-tags(Tag-set(T sc“), Tag-serf Bed ®*)) 
for some’ Kin 2 Kout and similarly for Joud‘aid’Jin. Phen’ ihe: same argtiment we used 


’ to show that the output of Sop, obeys the ‘tagtset ‘extension rule“shows that the output of 
Oswitch, does. Therefore we: conclude’ that Onwitch, & Recah ‘the Deo extension rule 
. as well as being isotone. ae ; 


Thacrem 6.5: Tie perry speraite 1 Zeite is euminus in. Sail of its arguments (by 


3 


The proof that Teiteh i is‘isotone is. more Stiga First we alow that. Iawitch is 


-isotone.on tagged-streams, then the isotonigity of: Jewiteh’ follows directly. from Theo- 


rem 6.1. We prove that‘Jewitch is isotone in ell ice 7's, arguments by showing that if for 
all OS ISN, Ts, €Taz,, then Iswitch(Tge, Tac, P35, .. Ta SJ ewiteh( Pgs; Tee, Tsz,,... 
Tsz,,) for any Tgs € Tag-set. This time. the. Proof proceeds by simultaneous induction on 


we 


the finite ordinals Dom(T2z)) = N55, note “that Pom(Tez,) =i} itt Taz, = 0), ‘and that ~ 


Iswitch(T gs, (), Tay. vss Ts, = QO, but that it is pot agcessarily true that Iswiteh( Tye, TS,» 
(dy. Tay) =m (), Substituting Tea, (for all I ). into the, definition of Iswitch we get: 


Iswitch (Tgs,Tsc,Tsx,,... Tez) = 
Uf Tsc=() Then), 
If Datum (Tse,)=0A Tez, ={ ) Then( 7 
If Datum (Tsc,)=NATsz, = ( ) Then () \ 
If Datum (Tsc,)=0 A Consistent-tags ( T ys, Tag-set € Tac!) , Tag-set¢ Tse,')) Then 
{ Datum ( Tez,') ;-Merge-tags (Fos, Taypdet (Pac!) ; ees 133) @ 
Iswitch (Merge-taget Tye, Tag-set( Pae' ), tele using) »), 
t Tac, 1 Tex,,...,T8xy) 


If Datum ( Tee, )= N A Consistent-tags (Tas ; Togeet( Tsc'), Tag-set ( Tsay! )) Then 
. (Datum ( Tey! ) , Marge-togs (1 Tas, Tag-set ( Tee! ), Tag-set ( Tey! INO 
switch ( Merge-tags (Togs, Tag-set' ( Tse! ), Tag-sat ( Toa, )), 
7 Tac, Tex,,...,7 Tety) 


Otherwise ( ) 
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We.assume in the steps that follow that Tsc #( ), since for any Ts,, Iswitch(Tgs,( ), Ts), 
.1.9T8y)™=(). The base step is: for allO <J.<N, Tsz,=() which implies for al OSI aN, 
Ts, = ( ) so thatl. awitch(Tgs, Tsc, T8,,..., 78 nw) = Iswitch(T ys, Tsc,(), ....4)) 
Iswitch(Tgs, Tsc, Tez,,... ,T'sz,). The induction step is; let 2, sve Dom (Taz ,) = N + 1. 
There are several cases to consider depending on whether Desa (Tee) = I or not, 
_ whether 7's,=¢) or not, and whether the tag-sets are éonsistent or not. | 


If ‘Datum(Tee!) =I and Ts,=(), then J switch(Tye, Tee, Ts, — .Te,) =() which is. 
the prefix of any tagged-stream. If Datum(Tec') =I and Ts, #4), then Ts,'=Taz,' and 
Ts, €tTsz,. Now if Tgs, Tag-set(Tso'} and: Tag-set(Ts;'} are not mutually consistent, 
then Iswitch(Tys, Tee, T3,,..., 73) =), which is the = ‘of any. tagged-nizeam. But if 
they are mutually consistent, then: — 


- Iswitch(Tys, Tse, T'8,,...,T8,5--.,T8y)= 
(Datum (Ts,'), Merge-tags(Tgs, Tag-set(Tse'), Tag-set (Ts,'))) @ : 
Iswitch (Merge-taga(Tgs, Tag-set( Tec! ), Tag-set (To, Ds 
t Tsc,Ts,,.. ey Dic, .sT8y) 


Iswitch (Tgs,Tsc,Tsx,,...,T8t,5-..5 Ts) = 
(Datum (Tsz,'),Merge-tags (Tgs , Tag-set (Tse! ), Tag-set ( Tsz,'))) ro) 
Iswitch ( Merge-tags (Ts , Tag-set ( Tse'), Tag-set ( Tez! )) . 
t Tsc,Ta,,...51 Tex,,...,T8y) 


Iswitch (Tgs,Tsc,Tsz,,...,T82)5...,T8ty) * 7 
(Datum (7s,'), Merge-tags(Tgse , Tag-set( Tae!) , Tag-set ( ,') ) ) KC) 
Iswitch ( Merge-tags ( T's, Tag-set(Tsc'), Tag-set (Ts,'))., 
T Tsc,T8,,...57 T8%,..-5T8y) 


+ Me 


Hence, by isotonicity of “®” we conclude that Iswitch(Tgs, Tse, T8,,...1T8j5 5 T8y) € 
Iewitch(Tgs, Tse, Tsz,,...,7z,,...,Tszy) given the induction hypothesis, that 
Iswitch(Tgam, TT sc, T8,,....TT835-.-s T8y) S Iswitch(Tgem, tT sc, T8545 ...9 TT8B 5 «.-5 T8y) 
where Tgsm = Merge-tags(...). In any case, we are reeneins pea <venDom(Tsz,), so the 


induction is well founded. 


Proving that Iswitch is isotone in its first argument (Tsc) is a relatively straightfor- 


ward induction (similar to that of Sop) and is therefore omitted. 
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The proof that [switch obeys the tag-set extension rule is more complicated than 
any of the previous such proofs. The reason for this is that the recursion schema 
includes an extra variable Tgs, which accumulates the tag-sets generated by the previous 


recursion levels. 


Now let Ts = Iswitch({ },7's,,...,T3y) and consider Ts’. Upon unwinding the 
recursion, we see that Tag-set(Ts,) = Merge-tags(Merge-tags(..., Tag-set(Tsc’—'), 
Tag-set(Ts,,°*)), Tag-set(Tsc”), Tag-set(Ts,,°)) (assuming Ts’ even exists). Now by 
associativity and commutativity of Merge-tags, we see that Tag-set(Ts,) = 
Merge-tags(Tag-set(Tsc’), Tag-set(Tsc’—'), ..., Tag-set(Ts,_°*), Tag-set(Ts,,%), ...) = 
Merge-tags(Merge-tags(Tag-set(T sc’), Tag-set(Tsc’~'), ...), Tag-set(Ts,,°), 
Tag-set(Ts,,°°), ...) But by since T'sc obeys the tag-set extension rule, Tag-set(Tse7~') & 
Tag-set(Tsc’) etc., thus by Lemma 6.5 we get Tag-set(Ts”) = Merge-tags(Tag-set(Tse’), 
Tag-set(Ts,_°*), Tag-set(Ts,,®), ...). Now we apply associativity and commutativity of 
Merge-tags again in order to group together the 7ss with the same subscript (i.e. to group 
together the data inputs) to get Merge-tags(Tag-set(T sc’), Merge-tags(Tag-set(T's,'), ...), 
...»Merge-tags(Tag-set(Ts,,'),...)). (Although we show 7s,' for all J, it must be 
understood that the whole M-tags subexpression is present iff IM < J: I € Datum(Tsc™)). 
Now by N applications of Lemma 6.5, we derive that Tag-set(7s 3) m= 
Merge-tags(Tag-set(T sc’), Tag-set(Ts,(oun(T#0)),, Tag-set(Ts,, ount(t#e-N))) where 
Count(T'se, I,J) is the number of times the value J appears in the set {Datum(Tsc™) | M 
<$J}. Bythe same argument, we also’. derive that Tag-set(Ts z) oa 
Merge-tags(Tag-set(Tsc*), Tag-set( T's, “unt T#e.0.K )), ..4, Tag-set(Ts, Count T#.N.K))) (again 
assuming that T's“ even exists). Since 7’sc and all 7's , obey the tag-set extension rule, we 
see that if K2J then Tag-set(Tsc’) © Tag-set(Tsc*) and Tag-set(Ts, Cm Tet) & 
Tag-set(T's P ialea ia *)) for all 1S N (since Count(Tsc, 1, J) $ Count(Tse, 1, K) for all I< 
N). Thus by N +1 applications of Lemma 6.4, we conclude that Tag-set(Ts’, 
Tag-set(Ts,,)) so that Ts obeys the tag-set extension rule too. Therefore we-have proved 


that Iswitch* obeys the tag-set extension rule as well as being isotone. 


Definition of Non-determinate Primitive Arbditer 


In order to define the Arbiter operator, we first define an auxiliary function 


Extend-tags which takes two arguments Choice and Tgs, and a parameter A. Extend-tags 
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appends the number Chotce on to the tail end of the Choice-sequence in the Tag, Tg (in 
Tgs), whose Arbiter-name is A. Its precise definition is: 


Extend-tags, (Choice, Tgs) = 
{Tg €Tgs | Arbiter-name(Tg)* A }U 
{lA » Choice-sequence ( Tg) @ Choice). | Ty € Tye Arbiter-name (Ty) =. A }. 


Where S@X=Sz 
And Dom (Sz) = Dom(S) + 1 
And Sz! = 1f I € Dom(S) Then S, Otherwise X 


The Arbiter, operator takes N +1 arguments which are ,tagged-streamses, Tee, and 
one parameter A which is the Arbiter-name (we omit further references to A ‘in the” : 
explanation). The Arbiter, applies Arbmerge, to each N +1- tuple from the Cartesian : 
product of the Tss’s and Profiz-reduces the result. Arbmerge, re takes N + 1 ‘tagged- 
streams and merges them all possible ways, producing a. Prefie-reduced set of tagged- 
streams as its result. It does this by using Arbmerge Ad: for each I $ N and ‘taking the 
. union of. their results. Each Arbmerge 4.7 Uses Arbmerge A recursively to. merge the tail of 
the /th tagged-stream with all the rest, and attaches the. head of the Ith tagged-stream to. 
each tagged-stream in the resulting set. The N sets which result at each recursion level — 
are united to form a single set which i is the overall result of that level. Arbmerge 4 and 
Arbmerge, ; both take an. additional argument, Tos Ginitially the set with one Tag whose 
Arbiter-name is A and whose Choice-sequence ig empty), which, records the arbitrary 
. choices made so far in the recursion. The precise definitions of. Arbiter ry Arbmerge A : 


_ and Arbmerge, , are; 


Arbiter ,(Tss,,...,T88,)™ 
{Tsa € U Arbmerge ,“(Tys,,Tsa,,..., Tay) | 
VT sb € U Arbmerge,“(Tys,,Ts8,,...,Tesy):Taad Tad} 
Where Tgs, = {(A,¢ ))} 


And Arbmerge,(Tgs,Ts,,...,T8,)= 
{Tea € U,.y Aromerge, ,(Tys,T2,,.. .T3y) | 
VTed« Urey Arbmerge, (Tye,Ts,,..., Tai}: Tea £Tsb } 


-67- 


And Arbmerge, ,(Tgs,Ts,,...,T8y)™ 
If Ts,=() Then {()} | 
If Consistent-tags ( Extend-tage, (I, Ts), Tag-set(Ts,')) Then 
{(Datum(Ts,'),Tgsz)@ Ts | 
Ts € Arbmerge ,(Tgsz,Ts,,... oT T8y5.0.5T8y IA © 
Tgsx = Merge-tags( Eztend-tags , (1,198), Tag-set(Ts,'))} 
Otherwise {()} 


The fact that Arbmerge ,° is continuous on its tagged-stream arguments, even though its 
result is a tagged-stream-set, will be made clear by Lemma 6. 10. ‘Note that the uses of . 
Arbmerge ,” in the definition of Arbiter , make use of our function-of-argument-sets 
convention only with. respect to the Tes,: although Tye, 4, is ‘a set, Arbmerge ra wants a 
_ such a set as its first argument. 


Continuity of the Non-determinate Arbiter 


To. prove that Arbiter , is isotone, we first prove‘ that Arbmerge , is izotone in its 
tagged-stream arguments. Note that the output domain is. the domain of Tagged-atream- 
‘seté while the input domain is that of Tagged-etreamhe: Since they are‘both posets however, 
isotonicity is well defined. First, however, we prove ‘another’ handy lemma about 


- tag-sets. 


Lemma 6.8: For any legitimate tag-set Ty, Tye Beend segs Al, Tye). 


From the definition of Exiting we see that an eee Tgx of Extend-tags (C, 
Tgs) is either already an element of Tgs (it Arbiter-namelT ga) * A) or it derives from 
the element Tga in Tys such that Arbiter-name(Tga) = Arbiter-name(T gz) and 
Choice-sequence( Tg) Choice-sequencel T92) Gt Arbiter-namo(T 92) =A). 


Lemma6.9: If VI < N: Ts, €Tsz, then Arbmerge AT 985 bie »T8,) q Arbmerge (Tg, 
T 82...) 18%). 


To show that this is true, we need an injection from Arbmerge Toe T8p;.. on TO nw) ta 
_ Arbmerge ,(T gs, Tsx,,...5 Pst) such that each element of the first is a prefix (“€") of 


an element of the second. Since Ts, $Ts2, for all L SN, we see that Tez,' = Ts, 
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(assuming the non-trivial case Dom(Ts,) * { }). Upon substituting Tsz, for Ts, in the 
definitions of Arbmerge, and Arbmerge, ; we get: 


Arbmerge (Ts, Tea, ,... Tz) ™ 
{Tsa €U,.y Arbmerge, (Tgs,Tsz,,...,Tezy) | 
VTsb € Ur. y Arbmerge, (Ts; Tex,, «2:5 Tety)t Fea d Tob} 


And Arbmerge, ,(Tgs,Tsz,,...,T8xy)™ 
If Tex,=() Then {()} 
If Conststent-tags ( Extend- tags, (I, 798), Tag-set(T4,!)) Then 
{(Datum(Ts,'), Tysz)@ Tea | i: . 
Tex € Arbmerge,(Tgsx, Tazy,.. 197 T82,,... Tay) A 
Tysx™ Merge-taga(Kztend-tags, (I,Tgs), Tag-set(Te,'))} 
Otherwise {()} 


Now consider astream Tsa in Arbmerge Kerr: T8,,..-5 + Thy), aad consider its first 
element. Tsa'. Clearly, Tsae Arbmerge y (Tas, hee " Ts,) ‘for. some T Tsa' = 
(Datum(Ts;' ), Tgsx),. and rTea € Arbmerge (Tyan, Fes +9 FT Rys ones TR yds, where Tysx= . 
-Merge-tags(Eatend-tags (I, Tge), Tag-eet{T's,')).- From this. -we conclude: that. Tea may - 
be characterized by its decision sequence. or “oracle” Jy..whenn;.K.< Dem(Tes). The 
same oracle may be applied to the elaboration of: 


Arbmerge,(Tgs,Tsx,,...,Tx,,) = 
{Tea€ U,., Arbmerge, ,(Tys,Tsz,,...,Taxy) | 
VTsbe Usain Arbmerne, (Ponsa, Tay): Toad Tab} 


This will give rise to a set of one or more streams since. the recursion can proceed at 
least as far as before (because T's is Tsz, for ail Z).. If we pick an arbitrary stream Tsax 
from this set, we easily see that Tsa ¢ Tsaz since the oracle Jy that generates Tsa 
generates a prefix of Tsaz, and the elements of that prefix are equal to the correspond- 
ing elements of T'sa since those elements derive from: the Te, “prefixes. of the T sz. 
Furthermore, if T'sb ¥ Tsa is in Arbmerge ,(Tgs, T's,,...,7'8,) the Tsbz.in Arbmerge (Te, 
Tez,,...,T'8z,,) of which it is a prefix must not equal Tsaz by Lemma 4.1. Thus we have 
established an injection from Arbmerge, (Ty, Tay, ... ,Ts,) to Arbmerge A(T 98 Tsz,, 

. Tsx,,) such that each element of the domain i is ae prefix of its image. ietae. 
Arbmerge AT 98s T3,,....T8y)9 Arbmerge, (T 9s, T8245... ,Tsz,). _ 
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Each stream in Arbmerge ,(Tgs, TS qs --+5 Ts) obeys the tag-set extension rule. This 


follows easily from Lemmas 6.6 and 6.8. 


The result of all this is that Arbmerge, is indeed isotone in its tagged-stream 
arguments and each element of its output prefix-reduced tagged-stream-set is a proper 


tagged-stream. 


Lemma 6.10: The completion Arbmerge ,* of Arbmerge, is continuous in its tagged- 


stream arguments Ts_. 


The fact that the output of Arbmerge, is a tagged-stream-set does not upset the 


continuity result of Lemma 6.7. All that is required is that the codomain is w directed — 


set complete, which it is since it is w chain complete. 


Now we can state and prove the key result of this chapter: the theorem that 
completes the basis for a denotational semantics of non-determinate data flow programs. 
It is.principally for this theorem that the chain complete poset of Tagged-stream-sets was 
developed in the last chapter. 


Theorem 6.6: The non-determinate Arbiter operator is continuous in each of its 


(tagged-stream-set) arguments. 


The proof of this is similar to the proof of Theorem 6.1. First, to shorten the text of 
the proof, we abbreviate Arbmerge ,(Ts,,...,T8,,....T8,) as Amp(Ts,) and 
Arbiter ,(T's8,, .... T88 py ..-, 188) as Ap(T'ss,), where the P-th argument is the one of 
interest. (During the rest of the proof, Ts, and Tss, will refer to an element of the 
respective chain, not to the J-th argument of Arbmerge, or Arbiter ,, unless otherwise 
stated or implied by appearance as an explicit argument.) Now, by Lemma 6.10 we 
know that Amp® is continuous and thus isotone. Let {Ts,, Ts8,,..-5 Tsst be a chain 
whose supremum is Tss, and consider the sequence of image sets {Amp*(Tss,), 
Amp(Tss,), -., Amp*(Tss)}. Note that this is not the extension of Amp*, just the 
8x4) 73} (where Ts, 


€ Tss,) isa chain whose supremum is Ts, then {Amp(Ts,), Amp"(T 8x so 


application of a function to a set of arguments. Now if {7's ot 
Amp“(Ts)} is a chain whose supremum is Amp*(Ts), by Lemma 6.10. We wish to 


establish an w + 1 sequence of injections from Ap(Tss,) to Ap(Tss,,,) and on to 


Ap(Tss) which demonstrates that they form a chain. Here we must depart from the 
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proof of Theorem 6.1 since the result of AmplTs) i is @ tagged-stream-set rather than a 
tagged-stream. Noting that Arbiter ,({Ts,}, ... {Te,}) = Arbmerge (Tos, T'8 55.09 T8y)s 
and that Ap(T'ssa) ¢ Amp“(T'ssa), suggests that we fori the union of the maps which | 
_ show that Amp*(Ts,}4 Amp*(Ts, ,,), uniting over all T's, € Tés,. We do this and then 
restrict the domain of this relation to the set Ap(Tss,) to get a function F,, since we 
_ thereby discard any first elements of the relation pair which were equal. That this 
function is injective follows easily from Lemma 4.1. Suppose F, (Tea) =F (Tb) where 
Tsa,Tsb¢€ Ap(Tss,). Then either Tsa € T'sb or T'sb< Tea by Lemma 4.1. But Ap(7 ss ,) is 
prefix-reduced, so this is impossible. Hence F, is ‘ad ‘inijection ‘from ‘Ap(Tss Pa to > 
| Ap(Tssy ,,) such that each element is a prefix of its “imidge, which’ establivhes that 
Ap(T esx) 4 Ap(Tss,,,). By repeating this construction sufficiently often (O +1 times!) 
we establish that {Tss,, Tes,,..., Tes} is indeed a chein-.of: sagged-stream-sets whose 
~ supremum is Ts, since each clement of Tes is the supremum: of a chain of  tagged- 
streams. Therefore we have proved that Ap is. ‘continudus; ut’ Powea: caeblbonry, so. 
Arbiter, is continuous in each argument. ww 


First Order Fix-Points of Non-determinate DFPL Programs: oe 


Having established that all the DFPL primitive operators a are continuous in their 
tagged-stream-set arguments, we conclude that any Tecursion-free DFPL. program can be 
| solved for its first order fixed-point behavior. as indicated i in Chapter 4. “The details of 
the data domain do not matter, as long as it is | @-chain complete. Similarly, the details 
of the operators do not matter, as long as they are continuous functions on | the domains. 


We will therefore undertake a simple fixed-point computation. 


Figure 6.1 shows a non-determinate DFPL Program with a loop, for which we will 
compute a first order fixed-point. Note that this time we introduce input from outside 
the loop. We do this to get a ‘non-trivial answer since. none of the opetators ‘in’ the loop 
generate any data. The Every-other operator is as. ‘defined in. Chapter 4 and will again 
ensure finiteness of the result. The Arbtter operator is as defined earlier i in this chapter 
except that we drop the parameter A which distinguishes among Arbiter’ s since we only . 


have one of them. 


Ws 


To solve this loop, we cut it at the point labeled X, then we solve the equation X= 
Arbiter({(A , B)}, Every-other(X)). To make the solution process more illuminating, we 
introduce the auxiliary variable Y,and generate approximate solutions to the above 
equation in two steps: Y, = Every-other(X,) and X,,, = Arbiter({(A, B)}, Y,). Naturally 


we start the approximation with X, = 1 ={()}. The first approximation is: 
X, = Arbiter ({(A,B)},£0)})= { (Ao, Boo) } 
Y, = Every-other(X,)={(Ao)} 
The second approximation is: . 
X,=Arbiter({(A,B)},Y,)= {(Ao,Boo,Aoor),(Ao,Ao1,Bo10) } 
Y, = Every-other(X,)= {(Ao,A001), (Ao, Boro) $ 


Note that the fact that the second input to Arbiter is already tagged (by this selfsame 
Arbiter) constrains the way that Arbmerge can do its merging — the tag generated by 
Extend-tags must be consistent with the input tag. The third approximation is: 


x, = Arbiter({(A,B)}, Y,)= { (Ao, Boo,A001,A0011 ),(Ao,A01,Bo010,Bo101 ) f 
¥, = Every-other(X,)™ {(Ao,Ao01), (Ao, Boro) ¢ 


Note that the tags as well as the data is dropped by Every-other from the output tagged- 
streams — the output therefore indicates only those arbitrary decisions that actually 
entered into the particular output. Note alsothat the generation of X, involves 
Prefiz-reduction. Part of the computation of X, involves evaluating Arbmerge((A, B), 
(Ao,Aoo1)), This generates the empty tagged-stream and the tagged-stream (Ao, Ao, 
Boo), both of which are discarded by the Prefiz-reduction which occurs when Arbiter 


generates its result tagged-stream-set. 


Since Y, = Y; the fixed-point computation has converged and the solution is X= 
{(Ao, Boo, A001, A0011), (Ao, Ao1, Bo10, Bo101)}. If we were cut the graph at Y instead of X, 
the first approximation would start with Y, = {()}, so that X, = Every-other( Y= {0}. 
This would delay the convergence by 1 step, but the fixed-point would obviously be the 


same. \ 
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<7 
Conclusion 


Overview 


This chapter ties up loose ends and suggests directions for future work in the | 
semantics of Data Flow Languages. Some of the loose ents considered are: “fairness” 


_ of non-determinate DFPL programs, functional behavior. of DFPL ‘programs with loops 


and recursion, and the meaning of ‘‘bottom” (or 1) in DFPL’ s° semantics. Directions -for 
future work are suggested in the areas of: our semantics as a ‘means. to proving ‘equiva. . 
lence of DFPL programs, operators as valid DFPL data. and the relation to reflexive 


domains. 


Explanation of the Anomaly of Brock and:Ackerman 


In [B&A-77], Brock and Ackerman present two small non-determinate data flow 
programs which exhibit anomalous behavior. The anomaly is that their operational 


_ behavior is different from the behavior predicted by a simple denotational semantics 


based on sets of streams. From this, they correctly conclude that a semantics based only 
on sets of streams (which they call histories) is ‘inadequate to characterize non- 
determinate systems, In our model, based on set. of tagged streams, their two programs 
correspond to di ff erent functions, and thus their different. behavior i is not anomalous. In 
particular, the first stream element output by the second program is tagged, while the 
first stream element output by the first program is not tagged. The details of this may 
easily be filled in by examining their note, and will not be elaborated here. 


““Fairness’’ and the Arbiter 


As mentioned in Chapter 1, a non-determinaté- service program. may or may not 
treat its users ‘“‘fairly’’. . The usual definition of'a “fair” program . is that the program 
never keeps the user who requests service waiting for more than a specified or reasona- 
ble period of time. This can be refined by specifying what period of time is permissible. 
Two possibilities are: no user need wait an infinite amount of time for a request to be 
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serviced; no user need wait more than a bounded amount of time for a aa to be 


: serviced after it is Presented to the iyrem 


Neither of these definitions of “fairness” are dicey applicable to DFPI, since its 
semantics has no notion of time in the usual sense. The semantics of DFPL does, 
however, have the notion of relative order of appearance of data items. (This ordering 
is induced by the ordering of the positive ititegets which if the domain of the function 
which defines a Tagged-etream.) Thus the above definitions of “fairness” can be recast 
as follows: any user’s Tequest will be serviced after a ‘finite’ number of other users’ 
requests are serviced; any user’s request will be serviced after a bounded number of 
other users’ requests are serviced. Let us now investigate whether either ot these 
definitions of “fairness” can be satisfied within th the semantics of DFPL. 


Since the source of all non-determinate: behavior in. DFPL.is the Arbiter, the ques- 
tion boils down to the “‘fairness” of the Arbster. : That is,’ if several sources of requests — 
are to be merged into one for consideration by. some processing program, even if the 
program: has internat queues for unsatisfied: requests, the Arbiter makes the initial 
decision as to which request gets served or even. — for service. 


Recall that neither in the determinate semantics of streams (cf. Cuiseee 4) nor in 
the non-determinate semantics of tagged-stream-sets, (cf. Chapter 6) .do we have the 
notion of a datum i in one stream Preceding. or following. a datum in another stream. 
Therefore, we cannot even express the concept of a datum not being delayed at an 
Arbiter while more than a bounded number of other inputs~ are processed. There is 
another related concept which is expressible however. ‘That is the idea any stream which - 
is the output of an Arbiter will never have more than a ‘bounded number of’ contiguous 
data items which are passed thtough from any single input stream. This could ‘easily be 
realized by changing the definition of the Arbmerge, sybfunction (cf. Chapter 6) to 
have extra arguments which counted how many data. items from each input have been 
accepted so far and constraining thereby which Arbmerge,! subfunction was to be called 
at each recursion. Unfortunately, this approach has a crippling flaw. Suppose the 
- bound on the number of contiguous acceptances is N and suppose that one input to the 
Arbiter is presented with a stream of length N+ Mand the other inputs with empty 
streams. Then the output can only consist of the first “N data items of the tion-empty 
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input stream, the remaining M items will never be accepted. . Thus. in the name of © 
bounded delay ‘fairness’, we impose in fi inite deity, in certain circumstances! Therefore 
we can reject bounded delay “fairness” as incompatibie with: ‘our fairly lepies semantics 
‘of DFPL. 


said to have finite delay if 2 any input ‘datum eventually shows u up.i in 1 the output stream no 
matter what sequence of arbitrary (but allowable), decisions were made by the Arbiter. 
More precisely, we would say that for any input stream ‘Ts, 8 and for any Ji in its domain, 
then for any output stream 7's in the output taggod-stream-set 1 Tas there exists a finite K 
such that Ts =7s,7. Now imagine a two input Arbiter such ‘that its. left ‘input is 
_ presented with the singleton stream a) (for simplicity, we ‘ignore the fact that the inputs = 

are really sets), and its:right inpet is‘ presented «with: the stream (B,B,...,B). The | 
output of this Arbiter, accorditig to its definition in . Chapter’: 6, must. be the. tagged: e 
-. streameset {(A, By .2.5 BD, (By Ay ons BY, ccsigdBy ».. By Ah: “(Here we drop the tags 
in the interest of brevity, they are: deducible from:the. data. which -are, distinct.). The last 
stream in this tagged-stream-set has the A all the.way at. ite-end..:No matter how long a 
finite stream of B’ s we feed it, the Arbiter will always produce such a stream as. an 
element of its output tagged-stream-set. Since the Arbiter i is ‘continuous, ‘its output ‘when 
confronted with an infinite input stream is the : supremum of its outputs generated from 
the finite ape streams which have that infinite stream ab ‘thei i Fare ome 


To. compute. this supremum, let us sdovt a bit. .) notation which departs somewhat ae 


from our previous notation. Let (A) stand for a stream of N occurrences of A, rather 
than the N-th element of a stream A, (We can distinguish this, usage by the precise 
typography of the letters A, 8 etc.) Then our example may be written as: 


©. Arbiter (A), (BY)) = 
{(BX,A,B*-") |osK<N}= 
{(BY,A)}u{(B* vA, BN-&) Lose! 


Now these tagged-stream-sets clearly comprise a hain. ‘tor increasing N (they must 

because Arbiter is isotone), and that chain has a supremum. By our construction: of 
such a supremum (cf. Chapter 5 ), each tagged-stream in each tagged-stream-set must be 
in a chain of tagged-streams which has a tagged-stream supremum. The Seesnon now is, 
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theory of fixed-points i in the function domain ‘the ‘séco! 


does the infinite stream (B°) appear in the supremal output set? The answer is ‘he, ~ 


because there is no chain of sequences in the chain of sets which has that infinite. stream: 
as its supremum. A set does exist which is an upper bound of the chain..of sets and . 
which contains that stream, but it would not be the /east upper bound. 


Therefore, although the continuity of the Arbiter precludes its being fair in the 


‘bounded delay sense, it is fair in the sense of having daly finite’ delay. 


Second Order Theory 


‘The set of continuous functions froma chain complete “poset to a chain complete 


poset themselves form a chain complete ‘posée tinder” ‘the “poinewise order’ “{Mar-77, 
~ Ros-77]. ‘That i is, FEC iff VE:F(8) 4 GUA). Thus, “equation 
‘have fixed-points which can, in ‘principle, be computed by the same ‘hethod, "We call the | 


is in’ such functions also: 


f"order theory to distinguish it 
from the first order theory of fixed-points in the domain of streams. There ‘are two basic 


- Classes of DFPL programs whose.functional fixedepoints, are, of interest: the iterative and 


the recursive... We shall first. consider.thess-separately.ip, ordar.to see how programs 
which have both iterative and recursive parts may be dealt with. . 


Figure 7.1 shows a prototypical DFPL définedieperator. with an: iterative body. We 
wish to determine what F is given G. That is, we have the equation Y = G(Y,X) but we 
desire an F such that Y = F(x). “This schema is ‘sufficiently ‘Beneral to encompass all 


as" 
ty Halbs 


iterative procedures. The variables x and ¥ ‘may in general be ‘tuples of tagged-stream- 


. sets where Y includes all feedback and ‘output paths and q includes the entire body of 


the procedure. If not ail feedback paths are desired as ‘outputs, an appropriate projec- 


tion function can be applied to Y to yield the. outputs, byt this changes the solution in a 


trivial way only. 


Let us assume that Gis continuous and that'G: DX D’» D where D is our chain 
complete domain. Let G, =A Y.G(X,Y). Then Gis contiiuous in its single argument. 
To solve Y= G(X, Y) for a given X is equivalent t6 séfvity ‘Y GCP); which is done by 


” finding LI{1,G,(1),6,(G,(.))}. To’solve for the F above However, we must ‘allow X to 
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be an actual argument. Therefore consider the sequence: 


FywvX.1 


F,=AX.G(X,2) 
F,=\X.G(X,G(X,4)) 
F,=\X.G(X,G(X,G(X,1))) : 


Clearly each F’, is a continuous function, because G is continuous in each argument, and 
both partial application and composition preserve, continuity. Also, the set iF, | r20} 
is a-chain in the function domain, that i is, F.€ fi. gf, x. oie This, follows by induction 
from the facts that G is igotone in its second argument, and vx: tas a, 1). Therefore, 
the chain has a continuous supremum. F =ULF, aes = ob which is the continuous function 
we wantey 


We conctade from this argument that any DFPL: procedure which has a loop for a 


‘body has a well defined semantic function whieh’ desdriies its ‘beliavior. 


Second Order Fixed Points of Recursive Programs 


Ft Pty, 


Figure 7.2 shows a prototypical DFPL defined operator with an recursive body. 
Again, by suitable bundling of data paths and repackaging of operators, any ‘recursively 
defined operator can be made to look like F. The equation to be solved. is thus Ya 


oe 
F(X) = H(GUX), F(Gr(x)), where Gl is the part of 6 that generates the left output and 


Gr is the part that generates the right output. ‘Since this equation must hold for all X, we 


abstract to get F =X. H(GUX), F(Gr(X))). Abstracting « once again, we convert this to 
the second order (or functional) equation F =A £.AX -H(GUX), B(GHX))MF). Thus 


we wish to find the (second order) fixed-point of the . functional A #.A X.H(Gi(X), | 


E(Gr(X))). But we. know that any such functional, consisting of compositions of (first 
order) continuous functions and function _ Variables, i is Asecond order) | continuous. 
Therefore, it has a least fixed-point, and that. fixed-point is the recursively defined 


function F. 
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We deduce from this argument that any DFPL procedure which has a recursive body 
corresponds to a well defined semantic function which describes. its behavior. Further- 
more, DFPL procedures which involve both loops and recursion can be solved in a similar 
manner to yield their overall semantic function. The proper way of determining the 
semantic function of a large program, consisting of many procedure definitions and uses, 
is of course to solve for the semantic function of as small units as possible, then to build 


up the function for the whole program out of these units. 


“Bottom’’, Strictness and Termination 


In most treatments of denotational semantics [Man-74, S&S-71, Sto-76] the bottom 
element of the data domain represents the totally undefined datum, while the bottom 
element of a function domain represents the totally undefined function. The bottom 
datum, 1, is then (reasonably enough) taken torepresent the ‘“‘result’’ of a non- 
terminating computation. That is, the partial function which the program computes is 
extended to a total function by defining it to yield 1 where it was otherwise undefined. 
Given this interpretation of 1, it is also reasonable to demand that most functions be 
“strict”, that is, that they yield 1 as their result if any of their arguments are 1. This 
follows from the operationally reasonable notion that it is impossible to invoke a subrout- 
ine until the computations of all of its arguments are finished. Strictness is not demand- 
ed of all functions however, the I f-then-else function is usually only strict in its predi- 


cate so that it can be used to terminate recursions and iterations. 


In the semantics of DFPL, the bottom element of the function domain indeed 
represents the totally undefined element, but the interpretation of 1 in the data domain 
must be different. The data domain of DFPL, recall, is based on the notion of Streams, 
therefore its bottom element is the (set consisting of) the empty stream. The empty 
stream, however, is definitely not the ‘result’ of a non-terminating computation, but 
rather is the definite result of a computation which has not yet received enough input to 
generate output on that port. (Note that much output may have appeared on another 
port, a luxury not permitted in most programming languages.) Furthermore, PFPL 
functions need not be strict at all. In fact, of the primitives, only the Oswitch and the 


Pcf’s are strict; the switch, Arbiter and especially the Hold (which has only one input) 
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are not strict. Therefore, 1 in the data domains of DFPL is not an “undefined” element 
which is added out of mathematical necessity (ie. to totalize partial functions” and to 
Glean up the partial order) but is a rather natural object which i is as much a part of the 


notion of streams as zero is of the integers. 


Program Correctness and Equivalence 


As we stated in the introduction to this thesis, it is necessary to have a precise 
semantics for a programming language in order to be able to Prove things . about Ppro- 
grams. Given a denotational semantics for a programming language, as we have for 
DFPL, it may be possible to determine the overall: function: computed. bya program in. 
that language. Having done so, it may then be possible to shaw that this function meets — 
a specification (program correctness), or that it isthe  sante. overall . function . as that 
computed by another program (program equivalence), Our semaatics gives a basis for 
doing such proofs, but it does not make them. universally trivial, no-interesting and useful 
semantics can do that. However, our semantics incorporates a: model of non-determinate 
behavior, which many other semantics have trouble dealing. with... 


Referring back to Figures 2.10 and 2.1 1, we can now see ‘that these two miniature 

"programs are indeed equivalent in their overall functionality up to homomorphism 

(assuming that F is determinate and history independent, iz. ‘X"=F(U)): That is, the 

X, Y and Z outputs of program 2.10 are (singleton) sets of tagged streams, Whereas the 
outputs of program 2.11 are just streams, so we mist map ‘each singleton set to its. 
element and remove all tags. This result. follows directly. from the denotational defini- 
tions of the various operators, we will not give the details as they consist merely of 

substitution into the defining equations, and then applying the homomorphism. Note 
that the Arbdtter in Figure 2.10 is an augmented operator: ‘its horizontal output is a (set 

of) stream(s) of index numbers, appearing in synchronization with the regular (vertical) 

_ output, such that each number merely says which input port is currently selected. 


Operator Valued Data and Reflexive Domains 


As mentioned in chapter 3, our current denotational semantics for DFPL ae not 


include operators (functions) as data, and thus has no ‘need for reflexive domains. To 
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meaningfully add operators-to DFPL as data values; we would ‘neéd an Apply operator 
which would take such data as input. ‘Unfortuiiately, it isnot ‘clear how: to. define an 
_ Apply operator in an taformal operation sense, much less in a: precise. denotational sense. 

ris reasonable to aszunie that the Apply operator: would accept.a directed .graph or 

- equivalent representation:of the: function: it, wedseo-apply,.and that it would; “‘oonnect”’ 
that function to the ether inputs and outputs of.the Apply,.ad then ‘‘start up”. the new 
subnetwork. The problem with this.model i is: when,.dges. the . application . terminate? 
There is, of course, no problem with an operator which does not terminate, the peculiar- 
ity of Apply is that it seems inherentfy to’ neveraccept wide than ‘one function datum 
from it ostensible stream of function data: This is-die to'thé act that’ it is in© general 
undecidable whether a subnetwork has terminated-or‘not.* One might get: ‘around this 
difficulty by defining a more subtie: apply operator. : 


One possibility is the following: the Apply operator receives as input a representa- 
tion of a running subnetwork rather:than. just its. function. That is, it receives the 
network representing the operator together with any streams in progress. It also has an 
input, besides the inputs ind outputs which ‘ate coariected’t6 the application, which must 
be “pulsed” in order'to make the applied ‘subnetwork “exscute. one transition (we are 
taking in operational terms agaia). ‘The Apply operator. continues ‘renning ‘the subnet- 
- work being applied as long as this input ix. puled with ‘True. “When a False. is: supplied 
instead, the current: “state” of the:subnetwork is.dumped:qut on an aundiliary @utput port 


. Of the Apply. This output. value: may be fed-in:te the Aggly later to resume: execution. 


By thi¢ means we finesse the undecidability of tarmination: of .the applied. subnetwork, 

we leave it to the user-of the Apnly to detesmine when to. stop: This makes meaningful | 

_ the notion of a stream.of things ta.be appliegzit is meee S stream of jobs to a batch 
- operating system... 


Although, from the operational point of view, tlie” applicable object is a function 
network plus its interdial state: it ds’ just ‘anothier futiction of “streains fo ‘strearis from the 
~ denotational point of view, since such functions diready: exhibit the behavior: of having 
an internal state. The extension to non-determinaté « ‘tutictions: “Should fit into this 
framework as it did before the Apply operatir. This ‘suggests that we might want a 
reflexive domain [Sto-TT} as our underlying: dotitain, thet is, a dontain which not only 
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contains ordinary data but also the continuous functions from. that domaia to itself. This 
domain D would have to satisfy the equation.D-# Sete-o7'-tagged-streama-of (Q ® - 
D)), ‘where Q is the domain of simple data (numbers,. stringt, records etc.), and ‘‘a” 
denotes isomorphism, “‘@®”’ denotes disjoint: union, and [Ded] denotes:.the continuous 


- functions from D to D. This is neither the usual tefiexive: doman “equation; due to the” oe 


"presence of the set constructor, nor is it quite the power domain: Ts due. | to the 
pete Oe eee eee 


. This needs further research, both to investigata,. the . utility ‘sad, cleanliness of this | 
solution and to formulate it precisely in the.denotational model. (Note. that the Apply 


operator is not necessary in.order to have the pe subrontinns # it. more. is like the 
“program loader” of conventional operating. ystems. Jo, 


Relation to the Lattice Formatetion: of rite Type 


‘Dans Scott rim developed a rather pes pe at: computation _ based on 

. complete lattices and continuous fuactions.[Sco-76}. . His -underlying - approach is to 
model everything in terms of one universal domain, the domain #w.of all. subsets of the 
non-negative integers, which is an algebraic and continuous -lattice.as well. as being a 
topological space. In this domain, continuous functions on the domain. may be repre- 
sented by encodings of their graphs:{sets of argument-value pairs), as can data values 
themselves. Reminiscent of Godel numbering, encodings are sets of integers, that is, 

elements of Pw. A single number is encoded as the: singleton’. set containing that 
number. The finite subsets B, of Pw may be éhuitietated (as Ey ={K,)...Ky_,} 
where N= 5. ,2**) and the result of applying a (continuous) function Fito an arin) 
element of the domain is defined by F(X)= "{F(Ey) | Ey! sx } Since. functions map 
elements of Pw to elements of Pw, functions may, have, argum 
sets, e.g. 6U10+1=7U11. In fact, Scott is able, to. express. the both the lambda calculus | 
and a good amount of recursive function theory in this . domain, including proofs of 


nents. and, values which. are. 


validity of lambda conversion rules, the continuity of lambda. definable functions, the 
first and second recursion theorems, and the recursive non-enumerability, of equations in 


the lambda calculus. 
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The fact that functions take sets as arguments and deliver results which are sets 
‘Suggests that the domain #w might be useful for expressing non-determinacy. However, 
the main purpose to which Scott puts this capabilityis the definition of data types as 
virtually arbitrary subsets of Pw. He does this by introducing a class of functions called 
retracts which are idempotent functions on Pw that map the data type to identically to 
itself, and other elements onto the data type. Then, by defining operators which allow 
" combination of retracts, he is able to show that certain recursively defined data types are 
the minimal fixed-point solutions to equations involving retracts. For example, the data 
type of trees, both finite and infinite, is the solution to the equation Tree x Nil + (Tree x 
Tree) where ‘“‘+” and ‘‘x”’ are operators on retracts analogous to union and cartesian 


product. 


The generality of the domain Pw, in particular its ability to express sets of data, 
‘would make it a possibility as an underlying model of the semantics of non-determinate 
DFPL. Certainly the tagged-streams needed could be encoded as sets of integers as easily 
as functions can be. However, whether this would clarify the semantics is doubtful: 
encodings of this sort are rarely noted for their transparency. Nor is the explicit 
machinery for dealing with non-determinacy already developed in this model. The 
existence, completeness and continuity of the relevant domains and functions has already 
been established for non-determinate DFPL. The treatment of operators as data is 


_ probably better examined in the framework of power domains as noted below. 


Relation to Power Domains 


The powerdomain construction of Plotkin [Plo-76], as clarified by Smyth [Smy-78], 
bears some similarity to our poset of tagged-stream-sets, there are some important 
differences however. The most important is that Smyth assumes different domains, a 
domain S of states, and a domain R of resumptions (similar to continuations). The 
States are the states of the abstract machine, while the resumptions are mappings from 
states into sets of states (disjointly united with state, resumption pairs). The reflexive 
domain equation is thus Rx [S + #P(S © S x R)], where the powerset constructor, #, is 
needed in order to express possible non-determinacy. The problem then is, how does 


one solve such equations? 
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To. do this, Smyth introduces quasi-ordered predomains which are sets of outcomes 
of (non-determinate) computations. These are ordered by the “Milner ordering”, which 
is only a quasi-order: 


StTs 
Vx¥eS: 3Y eT: YSXA 
VYeT: 3X eS: YsxX 


The elements of this domain may be viewed as cross sections of : a tree which represents : 
the non-determinate computation; each path from the root ‘to a leaf ‘corresponds to a 
particular sequence of arbitrary choices made by an instance of the computation. Smyth 
observes that this model and this (quasi) ordering forces one to make “unwelcome 
identifications” of outcomes in forming the equivalence _ Glasses. neces ry for a true 
poset. He suggests that this could.be remedied by taking arcs of the trees rather than 
. ..fust theér-cross-aectioas.. This is essentially equivalent to ovr use of tagged- streacn-sets, 
except that we have streams of data. Tether, thaa. muceeasive outcomes obtained by letting 
the computation run ever. longer. Further Smyth suggests category theory 
asa basis for. the improved analysis, we. anke do o with the, more conventional mathemat- n? 
_ics of sets and sequences. 


Since our underlying domain, tagged-stream-edte; is a true: ‘poset. and has a aoe 
structure, it seems likely that our recursive domaitt equation : ‘stated: above ‘can. be solved 
ina straightforward manner using the techniques of Smyth and Plotkin. This is an 
_ especially promising area for future research. 


-83- 


-8- 
References... 


A & W-77E.A. Ashcroft and W.W. Wadge,, LU. CID, @ Nonprocedural Language with 


ADJ-77 


~ Ada-68 


B & A-77 


‘Bir-67 


Iteration, Commpenicetions of the ACM, Vol. 20, No. 7, duly 1977. 


J. A Goguen, IL Ww. Thatcher, E. G. Wagner and J. B. Wright, Initial ‘Algebra 
Semantics and Continuous Algebras. 1 Journal of the ACM, Vol. 24, No. 1, 
panuery 1977. 


D. A. Adams, 4 Com putational “Model with Data Sequenced “Control, 
Computation Group Tech. Memo 45, ‘Stanford’ University, May 1968. 


‘J.D. Brock and W. B. ‘Ackerman, An Anomal} yin the “Speci ff ications of 
Nondeterminate Packet S ‘ystems, MIT Peony ‘for’ Computer Science, . 
Computation Structures Group Note 33, 1977, ; 


G. Birkhoff, Lattice Theoiy, Americiti Mattiematical Society Colloquium 
Publications, Vol. XX°V, Asher. Math: Soi:, Providence R.I., 1967. 


Cc 7 O-78 R. Cartwright and D. Oppen, Unrestricted Procatuee Calls in Hoare’s Logie; 


Cic-76 


“2 Dens73 


Flo-67 


H& P-78 


Hoa-69 


Fifth Annual ACM Symposium on Lae Ot become ‘Languages, 


‘Tucson Arizona; -January bore ESS Poet Bee Ee 


E. Ciccarelli, Strict Semantic Equations Bee or Data Flow Papions, MIT | 
Laboratory for Computer’ Science,: Computation Structures Group Note 26, 
1976. = 


J. Dennis, First Version ofa Data. Flow, Procedure. ddtiguage, MIF Project 
MAC Computation Structures Group TM-93, May 1973, | 


R.W. Floyd, Assigning Meanings to. Programs,.Proc, American Mathematical 
Society Symposia i in Applied Mathematics, Val. 19, He! (pp. 19-31). 


D. Harel and V. Pratt, Nandeterminism in ‘Logics 2 f Programs, Fifth Annual 
ACM i a saa on acre of la aie eres Tucson coe 
January 1978.: 


C.A.R. Hoare, An Axiomatic Basis f is Com puter Programming, Communi- 


cations of thé ACM, Vol.12,/No. 12; Odteber.1969. 


Hoa-78 


“C.A.R. Hoate, Communicating Sequential Processes, Lecture at MIF; 1978. 


-84- 


K & M-78 G. Kahn and D. MacGuéen, Coroutines and Necwerhs 0 of Parallel voces’: 


Kah-74 


Kos-73 


Kos-73b 
.. Kos-76 
Kos-78 


Leh-76 


Luc-68 


unpublished memorandum, 197 8. 


Gilles Kahn, The semantics of a simple language fo or "parallel processing, 
Proc. IFIP Congress 1974, Stockholm Sweden, ‘North-Holland, Anisterdam, 
1974, 


_ P.R. Kosinski, A Data Flow Progranuning. Language, TBM Research Center 
‘Report RC4264, March 1973. 


P.R. Kosinski, A Data Flow Lensenge. fe or “Operating Ss ystems 
Programming, ACM SIGPLAN/SIGOPS: Interface. _Meeting, . ‘Savannah 
Georgia, April 1976. 


P.R. Kosinski, Mathematical Semantics 3 and Pate. Flow. Programming, Third 
Anaual ACM,Sympogium on Principles of Programming. Languages, Atlanta 
Georgia, January 1976. . 


PR. Kosinski, A Straight forward . Bienosatianal: Semantics for _Non- 


determinate Data Flow Programs, Fifth. Annual. AEM. Symposium on Princi- 
ples of Programming Languages, Facece Actacns, rcemartid 1978. 


D.J. Lehmann, Categories for Fixpoint-Semantics, Ph. D. Thesis, Hebrew 
University of Jerusalem. 


F.L. Luconi, Asynchronous: ap cmmiaee Structures, Ph.D. Thesis, MAC- 
TR49, MIT, Feb. 1968. 


M& B-67 S. Maclane and G. Birkhoff, Algebra, The: Macmillan ‘Company, 1967. 


M & R-76 G. “Markowsky and B.K. Rosen, Bases for Chain-com plete Posets, IBM 


Journal of Research and Developmiens, ‘itrck 1976. 


M & S-76 R. Milne and C. Strachey, A Theory of Programming. Language Semantics, 


Man-74 


Mar-76 


<nepmas and Hall, Haisieee Frees: iti 
Zohar Manna, Mathematical. Theory “ Computation, M McGraw Hill, 1974. 


G. Markowsky, Chain-com plete posets: and directed sets with applications, 
Algebra Universalis, 1976 (pp. 53- £0: 


-8§- 


Mar-77 


Pio-76 


Rod-67 


Ros-77 


S &S-71 


Sco-76 


Sim-69 


Smy-78 


Sto-74 


Sto-77 


G. Markowsky, Posets, Categories, Combinatorics and. Computation, Unpubl- 
ished course notes, IBM Research Center, 1977. . 


G. Plotkin, A Powerdomain Construction, SIAM Journal of Computing, Vol. 
5 No. 3, September 1976 (pp. 452-287). 


J.E. Rodriguez, A Graph Model for Parallel Computations, Ph.D. Thesis, 
Dept. of Electrical Engineering, MIT, 1967. 


Barry K. Rosen, Poset Theory of Computation, Unpublished notes, IBM 
Research Center, 1977. 


D. Scott and C. Strachey, Toward a Mathematical Semantics for Computer 
Languages, Proc. Symposium on Computers & Automata Ponecnns: Insti- 
tute of Brooklyn, Vol. 21, 1971 (pp. 19-46). ee 


D. Scott, Data Types as Lattices, SIAM ee of Computing, Vol. 5 No. 3, 
September 1976 (pp. 522-587). 


H.A. Simon, The science of the Ayaieisl; MIT Press, ee Mass., 
1969. 


M.B. Smyth, Power Domains, Journal of oe and sym Sciences, Vol 
16, 1978 (pp. 23-26). 


J.E. Stoy, A Textual Language for Dataflow Programs, Unpublished 
Memo, MIT Project MAC, Computation Structures Group, 1974. 


J.E. Stoy, Denotational Semantics: The Scott-Strachey Approach to 
Programming Language Semantics, MIT Press, Cambridge Mass., 1977. 


-86- 


Figure oa.4 


~§T7- 


FIGURE 2a 


ADF BCE 
O11010 Ce 


ABCDEF 


-83- 


FiguRE 2.3 


Figure a4 


-9Go- 


F I@uRE Q.5 


- qi- 


Fisore 2.6 


a cD 


. C074 

<— ofo{ 
SOE SB 446 

foo, 


{O10 
1100 


~9a- 


-94 - 


Figure a9 | 


-95- 


Figure 2.10 


-96- 


Figure at 


-97- 


Figvre Y.-L 


Every- 
OTHER 


ae 


-Wg- 


Figure 5.1 


<a? <3> cu> <5? 
d 


£<45> 
<S4> 


-~9q- 


Figure Sa 


-{00- 


Figure 6.1 


{ <a,3>$ 


~{0{- 


Figure 7.1 


~102- 


Figure “J-Q 


- {03- 


TS a OEIC, SRI SRM SEDI lab, 


Biographical Note 


Paul Kosinski was born in Chicago on 13 October 1942. He attended Norman 
Bridge public elementary school and The University of Chicago High School. 


He attended the University of Chicago from 1959 to 1968, receiving the Bachelor 
of Science i in Mathematics in 1963 and the Master of Science in Information Science in 
1968. During the period 1962 to 1969 he was employed in research and advanced 
development at the Institute for Computer Research and Computation Center of the 
University. From 1964 to 1969 he also taught Computer Science at the Illinois Institute 
of Technology. 


He spent 1969 to 1970 in the advanced operating systems group at NCR in Los 
Angeles. In 1970 he became a research staff member at the IBM T.J. Watson Research 


Center and became engaged i in programming system research. In 1973 he took an 
educational leave to attend M.I. T. He returned to the IBM Research Center in 1976 


where he continues investigating programming systems and tools. 


-104- 


